diff options
Diffstat (limited to 'results/classifier/accel-gemma3:12b/vmm')
878 files changed, 25826 insertions, 0 deletions
diff --git a/results/classifier/accel-gemma3:12b/vmm/1001 b/results/classifier/accel-gemma3:12b/vmm/1001 new file mode 100644 index 000000000..7dcd022ab --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1001 @@ -0,0 +1,2 @@ + +query the current cursor position with QMP diff --git a/results/classifier/accel-gemma3:12b/vmm/1005 b/results/classifier/accel-gemma3:12b/vmm/1005 new file mode 100644 index 000000000..d81f992f7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1005 @@ -0,0 +1,178 @@ + +blockdev-del doesn't work after blockdev-backup with incremental, which using dirty-bitmap +Description of problem: +After incremental backup with bitmap, blockdev-del doesn't work at target node. +Because of this, incremental backup cannot rebase to base node. +I refered this. https://qemu-project.gitlab.io/qemu/interop/bitmaps.html#example-incremental-push-backups-without-backing-files +Steps to reproduce: +1. `blockdev-add` incremental backup node +``` +echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-add","arguments":{"driver":"qcow2","node-name":"incre0","file":{"driver":"file","filename":"/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2"}}}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "return": { + } +} +``` +2. `blockdev-backup` with `vda` to target `incre0` node +``` +echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-backup", "arguments": {"device": "vda", "bitmap":"bitmap0", "target": "incre0", "sync": "incremental", "job-id": "incre0-job", "speed": 536870912}}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848370 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "created", + "id": "incre0-job" + } +} +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848431 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "running", + "id": "incre0-job" + } +} +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848464 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "paused", + "id": "incre0-job" + } +} +{ + "timestamp": { + "seconds": 1651050066, + "microseconds": 848485 + }, + "event": "JOB_STATUS_CHANGE", + "data": { + "status": "running", + "id": "incre0-job" + } +} +{ + "return": { + } +} + +``` +3. `query-block-jobs` check `incre0-job` is done +``` +echo '{"execute":"qmp_capabilities"}{"execute":"query-block-jobs"}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "return": { + } +} +{ + "return": [ + ] +} +``` +4. To release write lock (need to rebase in incre0.qcow2), `blockdev-del` +``` +echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-del","arguments":{"node-name":"incre0"}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N + +{ + "return": { + } +} +``` +5. `qemu-img rebase` +``` +qemu-img rebase -b base.qcow2 -u incre0.qcow2 + +qemu-img: Could not open 'incre0.qcow2': Failed to get "write" lock +Is another process using the image [incre0.qcow2]? +``` + +6. check `query-named-block-nodes` after `blockdev-del` +``` +{ + "return": [ + { + "iops_rd": 0, + "detect_zeroes": "off", + "image": { + "virtual-size": 53687091200, + "filename": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2", + "cluster-size": 65536, + "format": "qcow2", + "actual-size": 241340416, + "format-specific": { + "type": "qcow2", + "data": { + "compat": "1.1", + "compression-type": "zlib", + "lazy-refcounts": false, + "refcount-bits": 16, + "corrupt": false, + "extended-l2": false + } + }, + "dirty-flag": false + }, + "iops_wr": 0, + "ro": false, + "node-name": "incre0", + "backing_file_depth": 0, + "drv": "qcow2", + "iops": 0, + "bps_wr": 0, + "write_threshold": 0, + "encrypted": false, + "bps": 0, + "bps_rd": 0, + "cache": { + "no-flush": false, + "direct": false, + "writeback": true + }, + "file": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2" + }, + { + "iops_rd": 0, + "detect_zeroes": "off", + "image": { + "virtual-size": 240451584, + "filename": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2", + "format": "file", + "actual-size": 241340416, + "dirty-flag": false + }, + "iops_wr": 0, + "ro": false, + "node-name": "#block412", + "backing_file_depth": 0, + "drv": "file", + "iops": 0, + "bps_wr": 0, + "write_threshold": 0, + "encrypted": false, + "bps": 0, + "bps_rd": 0, + "cache": { + "no-flush": false, + "direct": false, + "writeback": true + }, + "file": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2" + }, + ...... + ] +} +``` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1007490 b/results/classifier/accel-gemma3:12b/vmm/1007490 new file mode 100644 index 000000000..e4697f588 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1007490 @@ -0,0 +1,13 @@ + +Missing binfmt string for init script. + +./scripts/qemu-binfmt-conf.sh + +needs + +echo ':armCompiler:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-static-arm-binfmt:P' > /proc/sys/fs/binfmt_misc/register + +Some executables (specifically compilers like /usr/libexec/gcc/armv7a-unknown-linux-gnueabi/4.5.3/cc1 on gentoo) have unusual headers, and don't get recognized as arm binaries. + +Bug also mentioned on my blog: +http://mirage335.dyndns.org/forums/viewtopic.php?f=4&t=11&sid=01f0ca9cc76c78b6f600fa25cc99d62b \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1011 b/results/classifier/accel-gemma3:12b/vmm/1011 new file mode 100644 index 000000000..f1abe1c13 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1011 @@ -0,0 +1,22 @@ + +hvf: RDTSCP capability not passed to guests +Description of problem: + +Steps to reproduce: +1. Run: +wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso +./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso + +2. login as "root" +3. type + +cat /etc/cpuinfo | grep rdtscp + +Expected result: cpu flag lines including rdtscp +Actual result: empty, with: + +warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27] +Additional information: +This patch apparently resolves the issue according to my tests: + +https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/ diff --git a/results/classifier/accel-gemma3:12b/vmm/1012023 b/results/classifier/accel-gemma3:12b/vmm/1012023 new file mode 100644 index 000000000..a1fa043e6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1012023 @@ -0,0 +1,6 @@ + +Windows 7 bluescreen STOP: 00000005D + +Hello, with installed windows, or with install cd I have a blue screen (crash) after the first windows logo, see the screenshot. + +Thanks to fix it. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1013888 b/results/classifier/accel-gemma3:12b/vmm/1013888 new file mode 100644 index 000000000..4b6247ac4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1013888 @@ -0,0 +1,8 @@ + +windows xp sp3 setup blank screen on boot + +When attempting to run Windows XP SP3 setup in qemu on a Lubuntu host with the following kernel: + +Linux michael-XPS-M1530 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +Qemu does not get past a blank screen after "Setup is inspecting your computer's hardware configuration" \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1017 b/results/classifier/accel-gemma3:12b/vmm/1017 new file mode 100644 index 000000000..40713027c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1017 @@ -0,0 +1,14 @@ + +Qemu Windows 10 restart bluescreen +Description of problem: +after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen +with following issue - Memory Manangement or shutting down you Host system, getting bluescreen. +Only after stoppingh using qemu vm reboot system. +Steps to reproduce: +1. start qemu vm, ty get some operations +1. then stop the qemu vm via console comands +1. rebooting or restarting Host system +1. by shutting down, you get Bluescreen +2. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1020484 b/results/classifier/accel-gemma3:12b/vmm/1020484 new file mode 100644 index 000000000..4aa3fe341 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1020484 @@ -0,0 +1,4 @@ + +RFE: Support spice via unix domain socket + +According to the man page, spice can be only used via TCP/IP in opposite to VNC, which can also be configured to listen on a unix domain socket. To make it easy to use spice without exposing the interface, please support unix domain sockets as well. I can try to provide a patch, if you can point me to the source code where TCP/IP socket is opened. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1025244 b/results/classifier/accel-gemma3:12b/vmm/1025244 new file mode 100644 index 000000000..a0c622b37 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1025244 @@ -0,0 +1,33 @@ + +qcow2 image increasing disk size above the virtual limit + +Using qemu/kvm, qcow2 images, ext4 file systems on both guest and host + Host and Guest: Ubuntu server 12.04 64bit +To create an image I did this: + +qemu-img create -f qcow2 -o preallocation=metadata ubuntu-pdc-vda.img 10737418240 (not sure about the exact bytes, but around this) +ls -l ubuntu-pdc-vda.img +fallocate -l theSizeInBytesFromAbove ubuntu-pdc-vda.img + +The problem is that the image is growing progressively and has obviously no limit, although I gave it one. The root filesystem's image is the same case: + +qemu-img info ubuntu-pdc-vda.img + image: ubuntu-pdc-vda.img + file format: qcow2 + virtual size: 10G (10737418240 bytes) + disk size: 14G + cluster_size: 65536 + +and for confirmation: + du -sh ubuntu-pdc-vda.img + 15G ubuntu-pdc-vda.img + +I made a test and saw that when I delete something from the guest, the real size of the image is not decreasing (I read it is normal). OK, but when I write something again, it doesn't use the freed space, but instead grows the image. So for example: + 1. The initial physical size of the image is 1GB. + 2. I copy 1GB of data in the guest. It's physical size becomes 2GB. + 3. I delete this data (1GB). The physical size of the image remains 2GB. + 4. I copy another 1GB of data to the guest. + 5. The physical size of the image becomes 3GB. + 6. And so on with no limit. It doesn't care if the virtual size is less. + +Is this normal - the real/physical size of the image to be larger than the virtual limit??? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1030666 b/results/classifier/accel-gemma3:12b/vmm/1030666 new file mode 100644 index 000000000..8eaf6bf14 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1030666 @@ -0,0 +1,31 @@ + +gdb can't proceed after a breakpoint + +Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/ +Host: Windows 7 Ultimate 64-bit +Guest: i386 system running MS-DOS 6.22 +Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 +Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + +Short description: +I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + +Steps to reproduce: +DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. +Data.vfd is a floppy image containing a single program (hello.com). +The aim is to debug the execution of hello.com with gdb. +Launch Qemu. +Launch gdb, an attach to qemu: + "target remote localhost:1234" +I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" +In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. +Examining the program gives expected results (such as "info reg" or "disassemble"). +At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. +The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + +Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1031 b/results/classifier/accel-gemma3:12b/vmm/1031 new file mode 100644 index 000000000..66e28a108 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1031 @@ -0,0 +1,43 @@ + +Intel 12th Gen CPU not working with QEMU Hyper-V nested virtualization +Description of problem: +When booting with Hyper-V + host-passthrough it gets stuck at tianocore, does not change until I reboot which then loops into windows diagnostics which leads nowhere. Done using Windows 10, tried using newest windows version and 1909. + +Specs: Manjaro Gnome 5.15 LTS, i5-12600k, z690 gigabyte aorus elite ddr4, rtx 3070ti. + +I’ve spent days trying to figure out what was messing with it and it turned out I could boot when messing with my CPU topology, for some reason my 12th gen + Hyper-V + host-passthrough only works with sockets. Cores and threads above 1 causes boot problems, apart from disabling vme which boots, but the hypervisor does not load. + +This fails (normal host-passthrough): +``` + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="1" dies="1" cores="6" threads="2"/> + </cpu> +``` + +This boots (-can only change sockets): +``` + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="12" dies="1" cores="1" threads="1"/> + </cpu> +``` + +This boots (-no hypervisor): +``` +<cpu mode="host-passthrough" check="partial" migratable="off"> + <topology sockets="1" dies="1" cores="6" threads="2"/> + <feature policy="disable" name="vme"/> + </cpu> +``` + +No matter what adjustment I do I cannot change the cores or threads or it will result in a boot failure, host-model just does not work once I boot the machine the host model changes to cooperlake. + +My current way of bypassing this is I’ve downloaded the QEMU source code, gone through cpu.c and modified the default skylake-client CPU model to match my CPU, then I added in most of my i5-12600k flags manually, this seems to work with a 35-45% performance drop in CPU and in ram. Without Hyper-V enabled and using the normal host-passthrough I get near bare metal performance. + +Tried with multiple versions of QEMU, EDK2, and loads of kernel versions (to add to this my i5-12600k gen does not work on kernel version 5.13 and below) even went ahead to try Ubuntu and had the same problem, my other (i7-9700k) PC works fine with Hyper-V. Also disabled my E-cores through bios resulting in the same issue. CPU pinning the P-cores to the guest does not seem to help. +Steps to reproduce: +1. Enable hyper-v in windows features +2. Restart guest +3. Boot failure +Additional information: +Hyper-V host-passthrough XML: +https://pst.klgrth.io/paste/yc5wk diff --git a/results/classifier/accel-gemma3:12b/vmm/1035042 b/results/classifier/accel-gemma3:12b/vmm/1035042 new file mode 100644 index 000000000..74a704341 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1035042 @@ -0,0 +1,14 @@ + +Inconsistency in x509-dh-key-file parameter + +Hello, + +At source it is x509-dh-file, at config[2] it is x509-dh-key-file, at man[3] it is also x509-dh-key-file. + +I guess that [1] is not correct? + +Thanks! + +[1] http://git.qemu.org/?p=qemu.git;a=blob;f=ui/spice-core.c;h=4fc48f89026944fa91c4be349436041e97fc8654;hb=HEAD#l615 +[2] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-config.c;h=5c3296b8c6f0ec85201579f9a5f4e085adc33314;hb=HEAD#l498 +[3] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;h=5e7d0dc035978945e692efe3ef063b6a69e73b29;hb=HEAD#l888 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1036987 b/results/classifier/accel-gemma3:12b/vmm/1036987 new file mode 100644 index 000000000..5ecf63ce7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1038136 b/results/classifier/accel-gemma3:12b/vmm/1038136 new file mode 100644 index 000000000..5b7c2a1fc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1038136 @@ -0,0 +1,9 @@ + +lack of keycode 89 for br-abnt2 keyboards + +qemu-kvm-1.1.1 +host system: slackware64-13.37 +Bug detailed description: +Independent of Guest OS nothing happens when keycode 89 is pressed. +If you select option "-k pt-br" at qemu commandline you get keycode 89 but there is no more keycode 26 (dead_acute dead_grave) and keycode 51 fails on "less" sign. +If you have a numeric keyboard you can use its "slash" key but there is no means to use the question mark, causing discomfort when you are scripting or programming. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1040 b/results/classifier/accel-gemma3:12b/vmm/1040 new file mode 100644 index 000000000..bdc9f39ea --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1040 @@ -0,0 +1,7 @@ + +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze +Description of problem: +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well. + + + diff --git a/results/classifier/accel-gemma3:12b/vmm/1042 b/results/classifier/accel-gemma3:12b/vmm/1042 new file mode 100644 index 000000000..b572f5993 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1042 @@ -0,0 +1,21 @@ + +windows 10 guest freezes the host on shutdown +Description of problem: +Windows 10 guest sometimes freezes the QEMU host when shutting down. + +There has been a bug reported about this in the past here: +https://bugs.launchpad.net/qemu/+bug/1580459 + +I am also using PCI Passthrough with an NVIDIA GPU. +Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists. + +This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff. + +There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit. +The host almost never freezes if I do this, and only happens very rarely. +But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this. + +I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup. +Steps to reproduce: +1. Start Windows 10 guest. +2. Shutdown Windows 10 guest diff --git a/results/classifier/accel-gemma3:12b/vmm/1043 b/results/classifier/accel-gemma3:12b/vmm/1043 new file mode 100644 index 000000000..a87eb9a55 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1043 @@ -0,0 +1,11 @@ + +QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx +Description of problem: +- System does not boot. +- WHPX: setting APIC emulation mode in the hypervisor +- Windows Hypervisor Platform accelerator is operational +- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005) +- qemu: WHPX: Unexpected VP exit code 4 +Steps to reproduce: +1. Windows 11 / Ryzen +2. qemu-system-x86_64.exe --accel whpx --cpu max diff --git a/results/classifier/accel-gemma3:12b/vmm/1050 b/results/classifier/accel-gemma3:12b/vmm/1050 new file mode 100644 index 000000000..b40c9ba2b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1050 @@ -0,0 +1,73 @@ + +[BUG] heap-buffer-overflow in sifive_plic_create +Description of problem: +I run check-qtest-riscv64 in ubuntu20.04, and got a heap-buffer-overflow report with address sanitizer +HEAD: 7077fcb9b68f058809c9dd9fd1dacae1881e886c +Steps to reproduce: +run +`G_TEST_DBUS_DAEMON=/root/o/sources/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=58 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_BINARY=./qemu-system-riscv64 /root/o/sources/qemu/build/tests/qtest/test-hmp --tap -k` +Additional information: +I think is because on some conditions when after `j++(hw/intc/sifive_plic.c:458)`, it accesses `plic->addr_config[j](hw/intc/sifive_plic.c:463)` and results in heap-overflow. +I tried to modify `hw/intc/sifive_plic.c:463` to else-if, then the report gone. +Could you please have a check. +``` +==63425==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000031624 at pc 0x561afe157d54 bp 0x7ffcd8aef510 sp 0x7ffcd8aef500 +READ of size 4 at 0x602000031624 thread T0 + #0 0x561afe157d53 in sifive_plic_create ../hw/intc/sifive_plic.c:463 + #1 0x561afdc0ac7f in sifive_e_soc_realize ../hw/riscv/sifive_e.c:207 + #2 0x561afe6698fb in device_set_realized ../hw/core/qdev.c:531 + #3 0x561afe679b90 in property_set_bool ../qom/object.c:2273 + #4 0x561afe681c7f in object_property_set ../qom/object.c:1408 + #5 0x561afe68b763 in object_property_set_qobject ../qom/qom-qobject.c:28 + #6 0x561afe682535 in object_property_set_bool ../qom/object.c:1477 + #7 0x561afdc0a601 in sifive_e_machine_init ../hw/riscv/sifive_e.c:91 + #8 0x561afd34d608 in machine_run_board_init ../hw/core/machine.c:1427 + #9 0x561afda49697 in qemu_init_board ../softmmu/vl.c:2610 + #10 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2706 + #11 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2699 + #12 0x561afda504ee in qemu_init ../softmmu/vl.c:3737 + #13 0x561afd1cf4ae in qemu_main ../softmmu/main.c:35 + #14 0x561afd1cf4ae in main ../softmmu/main.c:45 + #15 0x7f9d13bf3082 in __libc_start_main ../csu/libc-start.c:308 + #16 0x561afd1de78d in _start (/root/o/sources/qemu/build/qemu-system-riscv64+0x271378d) + +0x602000031624 is located 8 bytes to the right of 12-byte region [0x602000031610,0x60200003161c) +allocated by thread T0 here: + #0 0x7f9d15026808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 + #1 0x7f9d14a84e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + +SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/intc/sifive_plic.c:463 in sifive_plic_create +Shadow bytes around the buggy address: + 0x0c047fffe270: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa + 0x0c047fffe280: fa fa 05 fa fa fa 07 fa fa fa fd fa fa fa 02 fa + 0x0c047fffe290: fa fa 00 01 fa fa fd fd fa fa fd fa fa fa fd fd + 0x0c047fffe2a0: fa fa 00 02 fa fa 00 02 fa fa 05 fa fa fa 07 fa + 0x0c047fffe2b0: fa fa 00 01 fa fa 07 fa fa fa 05 fa fa fa 07 fa +=>0x0c047fffe2c0: fa fa 00 04[fa]fa 04 fa fa fa 00 00 fa fa 00 00 + 0x0c047fffe2d0: fa fa 00 00 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe2e0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe2f0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe300: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fa + 0x0c047fffe310: fa fa fd fd fa fa 00 03 fa fa fd fd fa fa 00 03 +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==63425==ABORTING +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1054180 b/results/classifier/accel-gemma3:12b/vmm/1054180 new file mode 100644 index 000000000..8cc7805ad --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1054180 @@ -0,0 +1,17 @@ + +DNS activity in slirp (user networking) mode quickly depletes file descriptors and crashes qemu + +Hi, we have encountered quite some trouble with filedescriptor depletion of the qemu process. We have figured out that it can be demonstrated easily by doing a lot of DNS queries inside the VM -- in our real world scenario this is caused by running centos network install with a fast mirror. + +This situation is further problematic because qemu can't handle fd depletion very well: +1) if ulimit is 1024 then qemu hangs in infinite loop whenever it tries to open the 1025th fd +2) setting ulimit >1024 does not help that much because qemu uses select and max. fd set size is 1024 per default => qemu crashes because of buffer overflow in select() +3) setting ulimit > 1024 AND recompiling with large enough fd set size AND disabling gcc's fortify source seems to work, but that's really just a hot-fix + +The problem can be replicated quite easily by running something like + +while :; do echo >/dev/udp/10.0.2.3/53; done + +inside a Linux VM -- crash comes very soon. + +This problem is present in current qemu (1.2.0) and in earlier as well. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1054558 b/results/classifier/accel-gemma3:12b/vmm/1054558 new file mode 100644 index 000000000..f3ee8d9f7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1054558 @@ -0,0 +1,7 @@ + +1366x768 resolution missing + +I use ArchLinux with QEMU 1.2.0. +I found that 1366x768 resolution is missing, even if I use -vga std or -vga vmware. +I think that it is necessary to patch it into the source. +Also, why not add a command-line option to specify custom resolutions without patching the source? (I know that VirtualBox has a hidden option to add any resolution.) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1055 b/results/classifier/accel-gemma3:12b/vmm/1055 new file mode 100644 index 000000000..fe95dc428 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1055 @@ -0,0 +1,17 @@ + +QEMU does not close listening socket for incoming migration when post-copy migration breaks +Description of problem: +QEMU keeps listening on the incoming port even after breaking a post-copy +migration using "migrate-pause" QMP command. And even once migration is +finished after recovering it "migrate-recover" using a different port number. +If "migrate-recover" is called with a URI specifying the original port (which +is still in LISTEN state), QEMU reports "Failed to find an available port: +Address already in use". +Steps to reproduce: +1. start migration +2. wait for the first iteration to finish +3. switch to post-copy using "migrate-start-postcopy" +3. break migration with "migrate-pause" +4. check lsof -p $QEMU_PID +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1061 b/results/classifier/accel-gemma3:12b/vmm/1061 new file mode 100644 index 000000000..d1663c5f0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1061 @@ -0,0 +1,247 @@ + +xen/pt: Incorrect register mask for PCI passthrough prevents Linux guest from completing boot process +Description of problem: +In brief, the problem is that PCI/GPU passthrough functions normally with Xen/Qemu if the Xen HVM guest is Windows, but if the guest is Linux, the guest will not complete the booting process and it never reaches the systemd targets that allow the GUI environment to start and login to the desktop environment. The problem is that a bug in the way Qemu initializes the PCI status register of the passed through devices causes the PCI capabilities list bit of the PCI status register to be disabled instead of enabled. This in turn disables the MSI-x interrupt handling capability of the passed through PCI devices. I think the reason only Linux guests are affected is that Linux guests use a different method of delivering interrupts from the passed through PCI devices to the guest from the method used by Windows guests, and the method used by Windows does not require the MSI-x capability of the PCI devices but the method used by Linux does need the MSI-x capability of the passed through devices. I will explain this further in the additional information section with logs and other relevant information. +Steps to reproduce: +1. It might only be reproducible on specific hardware. It is very reproducible on my system, an ASRock B85M-Pro4 with BIOS version P2.50 and a Haswell core i5-4590S CPU. +2. Configure the system to pass through the Intel integrated graphics device (IGD), the on-board USB 3 controller, and the onboard PCI audio device to a Windows Xen HVM guest with Qemu running as the device model for the Windows guest in Dom0 using the Xen xl toolstack, and verify that the Windows guest boots and functions properly. This is not trivial and can probably only be done by persons familiar with Xen and its PCI and VGA/GPU passthrough feature. Here is the xl domain configuration file that the Xen xl toolstack used to create and boot the working Windows HVM domain with passthrough of three PCI devices on my hardware: +``` +builder = 'hvm' +bios = 'seabios' +memory = '3072' +vcpus = '4' +device_model_version = 'qemu-xen' +disk = ['/dev/systems/windows,,xvda,w'] +name = 'bullseye' +vif = [ 'model=e1000,script=vif-route,ip=<redacted>' ] +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'destroy' +boot = 'c' +acpi = '1' +apic = '1' +viridian = '1' +xen_platform_pci = '1' +serial = 'pty' +vga = 'none' +sdl = '0' +vnc = '0' +gfx_passthru = '1' +pci = [ '00:1b.0', '00:14.0,rdm_policy=relaxed', '00:02.0' ] +``` +3. Shut down the working Windows Xen HVM and replace it with a Linux Xen HVM disk image and try to boot that in place of Windows, keeping all other configuration options the same as with the working Windows guest. To create and boot the non-working Linux HVM domain, I used the same xl domain configuration as for Windows with the exception that the disk line was replaced with: +``` +disk = ['/dev/systems/linux,,xvda,w'] +``` +which obviously points to a virtual disk that boots Linux instead of Windows. A Linux guest, such as Debian bullseye or Debian buster or Debian sid will not boot properly and instead exhibit the problem handling IRQs from the passed through PCI devices, as discussed above. +Additional information: +This problem is known by QubesOS and they have been using a patch to fix it since 2017, but they give very few details about the problem in their commit messages: + +https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3/commits/ab2b4c2ad02827a73c52ba561e9a921cc4bb227c + +That same patch to hw/xen/xen_pt_config_init.c also fixes the problem on my system. + +Some logs: + +Without the QubesOS patch, I get error messages indicating problems handling IRQs like this in the Dom0: + +May 10 08:50:03 bullseye kernel: [79077.644346] pciback 0000:00:1b.0: xen_pciback: vpci: assign to virtual slot 0 +May 10 08:50:03 bullseye kernel: [79077.644478] pciback 0000:00:1b.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.644732] pciback 0000:00:14.0: xen_pciback: vpci: assign to virtual slot 1 +May 10 08:50:03 bullseye kernel: [79077.644874] pciback 0000:00:14.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.645024] pciback 0000:00:02.0: xen_pciback: vpci: assign to virtual slot 2 +May 10 08:50:03 bullseye kernel: [79077.645107] pciback 0000:00:02.0: registering for 16 +May 10 08:50:30 bullseye kernel: [79105.273876] vif vif-16-0 vif16.0: Guest Rx ready +May 10 08:50:30 bullseye kernel: [79105.273893] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready +May 10 08:50:30 bullseye kernel: [79105.278023] xen-blkback: backend/vbd/16/51712: using 4 queues, protocol 1 (x86_64-abi) persistent grants +May 10 08:50:44 bullseye kernel: [79119.104937] irq 16: nobody cared (try booting with the "irqpoll" option) +May 10 08:50:44 bullseye kernel: [79119.104973] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1 +May 10 08:50:44 bullseye kernel: [79119.104976] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B85M Pro4, BIOS P2.50 12/11/2015 +May 10 08:50:44 bullseye kernel: [79119.104979] Call Trace: +May 10 08:50:44 bullseye kernel: [79119.104984] <IRQ> +May 10 08:50:44 bullseye kernel: [79119.104998] dump_stack+0x6b/0x83 +May 10 08:50:44 bullseye kernel: [79119.105008] __report_bad_irq+0x35/0xa7 +May 10 08:50:44 bullseye kernel: [79119.105014] note_interrupt.cold+0xb/0x61 +May 10 08:50:44 bullseye kernel: [79119.105024] handle_irq_event+0xa8/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105030] handle_fasteoi_irq+0x78/0x1c0 +May 10 08:50:44 bullseye kernel: [79119.105037] generic_handle_irq+0x47/0x50 +May 10 08:50:44 bullseye kernel: [79119.105044] __evtchn_fifo_handle_events+0x175/0x190 +May 10 08:50:44 bullseye kernel: [79119.105054] __xen_evtchn_do_upcall+0x66/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105063] __xen_pv_evtchn_do_upcall+0x11/0x20 +May 10 08:50:44 bullseye kernel: [79119.105069] asm_call_irq_on_stack+0x12/0x20 +May 10 08:50:44 bullseye kernel: [79119.105072] </IRQ> +May 10 08:50:44 bullseye kernel: [79119.105079] xen_pv_evtchn_do_upcall+0xa2/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105084] exc_xen_hypervisor_callback+0x8/0x10 +May 10 08:50:44 bullseye kernel: [79119.105091] RIP: e030:xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105097] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc +May 10 08:50:44 bullseye kernel: [79119.105100] RSP: e02b:ffffffff82603de8 EFLAGS: 00000246 +May 10 08:50:44 bullseye kernel: [79119.105106] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff810023aa +May 10 08:50:44 bullseye kernel: [79119.105108] RDX: 0000000009d62df2 RSI: 0000000000000000 RDI: 0000000000000001 +May 10 08:50:44 bullseye kernel: [79119.105111] RBP: ffffffff82613940 R08: 00000066a1715350 R09: 000047f57b235dc9 +May 10 08:50:44 bullseye kernel: [79119.105114] R10: 0000000000007ff0 R11: 0000000000000246 R12: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105117] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105124] ? xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105133] ? xen_safe_halt+0xc/0x20 +May 10 08:50:44 bullseye kernel: [79119.105140] ? default_idle+0xa/0x10 +May 10 08:50:44 bullseye kernel: [79119.105145] ? default_idle_call+0x38/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105152] ? do_idle+0x208/0x2b0 +May 10 08:50:44 bullseye kernel: [79119.105158] ? cpu_startup_entry+0x19/0x20 +May 10 08:50:44 bullseye kernel: [79119.105164] ? start_kernel+0x587/0x5a8 +May 10 08:50:44 bullseye kernel: [79119.105170] ? xen_start_kernel+0x625/0x631 +May 10 08:50:44 bullseye kernel: [79119.105180] ? startup_xen+0x3e/0x3e +May 10 08:50:44 bullseye kernel: [79119.105184] handlers: +May 10 08:50:44 bullseye kernel: [79119.105222] [<000000005d228d5f>] usb_hcd_irq [usbcore] +May 10 08:50:44 bullseye kernel: [79119.105245] [<00000000e534b010>] ath_isr [ath9k] +May 10 08:50:44 bullseye kernel: [79119.105257] Disabling IRQ #16 + +Also, without the patch, I get error messages about failure to handle IRQs in the Linux Xen HVM guest: + +Oct 23 18:50:32 domU kernel: irq 36: nobody cared (try booting with the "irqpoll" option) +Oct 23 18:50:32 domU kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-9-amd64 #1 Debian 5.10.70-1 +Oct 23 18:50:32 domU kernel: Hardware name: Xen HVM domU, BIOS 4.14.3 10/22/2021 +Oct 23 18:50:32 domU kernel: Call Trace: +Oct 23 18:50:32 domU kernel: <IRQ> +Oct 23 18:50:32 domU kernel: dump_stack+0x6b/0x83 +Oct 23 18:50:32 domU kernel: __report_bad_irq+0x35/0xa7 +Oct 23 18:50:32 domU kernel: note_interrupt.cold+0xb/0x61 +Oct 23 18:50:32 domU kernel: handle_irq_event+0xa8/0xb0 +Oct 23 18:50:32 domU kernel: handle_fasteoi_irq+0x78/0x1c0 +Oct 23 18:50:32 domU kernel: generic_handle_irq+0x47/0x50 +Oct 23 18:50:32 domU kernel: __evtchn_fifo_handle_events+0x175/0x190 +Oct 23 18:50:32 domU kernel: __xen_evtchn_do_upcall+0x66/0xb0 +Oct 23 18:50:32 domU kernel: __sysvec_xen_hvm_callback+0x22/0x30 +Oct 23 18:50:32 domU kernel: asm_call_irq_on_stack+0x12/0x20 +Oct 23 18:50:32 domU kernel: </IRQ> +Oct 23 18:50:32 domU kernel: sysvec_xen_hvm_callback+0x72/0x80 +Oct 23 18:50:32 domU kernel: asm_sysvec_xen_hvm_callback+0x12/0x20 +Oct 23 18:50:32 domU kernel: RIP: 0010:native_safe_halt+0xe/0x10 +Oct 23 18:50:32 domU kernel: Code: 02 20 48 8b 00 a8 08 75 c4 e9 7b ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d a6 6f 54 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 96 6f 54 00 f4 c3 cc cc 0f 1f 44 00 +Oct 23 18:50:32 domU kernel: RSP: 0018:ffffffff89003e48 EFLAGS: 00000246 +Oct 23 18:50:32 domU kernel: RAX: 0000000000004000 RBX: 0000000000000001 RCX: ffff8dbb7cc2c9c0 +Oct 23 18:50:32 domU kernel: RDX: ffff8dbb7cc00000 RSI: ffff8dbaf55b1400 RDI: ffff8dbaf55b1464 +Oct 23 18:50:32 domU kernel: RBP: ffff8dbaf55b1464 R08: ffffffff891b9120 R09: 0000000000000008 +Oct 23 18:50:32 domU kernel: R10: 000000000000000e R11: 000000000000000d R12: 0000000000000001 +Oct 23 18:50:32 domU kernel: R13: ffffffff891b91a0 R14: 0000000000000001 R15: 0000000000000000 +Oct 23 18:50:32 domU kernel: ? xen_sched_clock+0x11/0x20 +Oct 23 18:50:32 domU kernel: acpi_idle_do_entry+0x46/0x50 +Oct 23 18:50:32 domU kernel: acpi_idle_enter+0x86/0xc0 +Oct 23 18:50:32 domU kernel: cpuidle_enter_state+0x89/0x350 +Oct 23 18:50:32 domU kernel: cpuidle_enter+0x29/0x40 +Oct 23 18:50:32 domU kernel: do_idle+0x1ef/0x2b0 +Oct 23 18:50:32 domU kernel: cpu_startup_entry+0x19/0x20 +Oct 23 18:50:32 domU kernel: start_kernel+0x587/0x5a8 +Oct 23 18:50:32 domU kernel: secondary_startup_64_no_verify+0xb0/0xbb +Oct 23 18:50:32 domU kernel: handlers: +Oct 23 18:50:32 domU kernel: [<000000007d3a0964>] usb_hcd_irq [usbcore] +Oct 23 18:50:32 domU kernel: Disabling IRQ #36 +Oct 23 18:50:32 domU kernel: PM: Image not found (code -22) +Oct 23 18:50:32 domU kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:45:pipe A] flip_done timed out + +To prove the cause of the bug, I compare some logs without the patch +and with the patch that fixes it. + +First, relevant logs generated by Qemu in Dom0, for existing Qemu without the patch. On Debian these logs are located in /var/log/xen in the Dom0: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0280. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0080. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +Next, the same logs, but now using a version of Qemu with the patch that fixes the bug: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0290. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0090. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +To decipher what is happening here, one must refer to the definitions +in the pci/header.h file from PCI Utilities that in Debian is in the +libpci-dev package and is probably in similarly named packages on other +distros. + +The Offset of 0x0006 corresponds to the 16-bit PCI_STATUS register of +the passed through device, and the Emulated value of 0x0010 sets the desired +emulated value of the PCI_STATUS_CAP_LIST bit to 1 in the PCI_STATUS register. +The host values of 0x0290, 0x0090 correspond to the setting of the register in the +physical device for real device 00:14.0 and 00:02.0, respectively. +The syncing to value indicates the value of the register that Qemu +exposes to the guest. Notice that without the patch, the PCI_STATUS_CAP_LIST +bit is turned off for the two PCI devices (register value = 0x0280 and 0x0080 +for real device 00:14.0 and 00:02.0, respectively), but the bit is turned +on (0x0290 and 0x0090) for these devices with the patch. With the capabilities list enabled, the guest can use the MSI-x capability of the device, but with the capabilities +list disabled, the guest cannot use the MSI-x capability of the devices. +That explains why this patch is needed in Qemu to fix this problem and enable the Linux guest to use the MSI-x capability of the passed through PCI devices. + +This is the QubesOS patch thatfixes it: +``` +--- a/hw/xen/xen_pt_config_init.c ++++ b/hw/xen/xen_pt_config_init.c +@@ -1969,7 +1969,7 @@ + /* Mask out host (including past size). */ + new_val = val & host_mask; + /* Merge emulated ones (excluding the non-emulated ones). */ +- new_val |= data & host_mask; ++ new_val |= data & reg->emu_mask; + /* Leave intact host and emulated values past the size - even though + * we do not care as we write per reg->size granularity, but for the + * logging below lets have the proper value. */ +``` +The QubesOS patch that fixes it in Debian's Qemu 7.0.0 build is also attached as a file.[xen-fix-emu-mask.patch](/uploads/3bef189175549cd9854f8dc3d1affc88/xen-fix-emu-mask.patch) + +~~I will not officially submit it as a patch because I am not its author.~~ + +~~I do not know why QubesOS never officially requested that this fix +be committed to Qemu upstream, but I hope after review by the +maintainers of the code touched by this patch it will be recognized +as a necessary fix to a mistake that causes the desired merge of +the host and emulated values to be incorrect.~~ + +For reference, the commit that is fixed by the QubesOS patch is: + +Fixes: 2e87512eccf3c5e40f3142ff5a763f4f850839f4 (xen/pt: Sync up the dev.config and data values.) + +I think perhaps that commit and the patched file might need some other cleanup so I might try my hand at officially submitting a patch to Qemu that fixes this issue on my hardware without breaking something else, because it is possible that the simple QubesOS patch is not suitable as the correct fix. + +But before I do that, I wish to make one more comment. In my logs, the only other register than the PCI_STATUS register that is affected by the QubesOS patch is the PCI_HEADER_TYPE register. Without the patch, the register's value is always exposed to the guest as 0x80, and with the patch, the value is always exposed as 0x00 (PCI_HEADER_TYPE_NORMAL as defined in pci/header.h). That is because Qemu sets the initial emulated value of PCI_HEADER_TYPE register to 0x80, but Qemu also sets the emu_mask to 0x00, so after correcting the merging of the host and emulated values with the QubesOS patch, the value is synced to 0x00 instead of 0x80. What I don't understand is why the register is initialized with 0x80, but the emu_mask is 0x00. Shouldn't the emu_mask be 0x80, to pass through the initial emulated value of 0x80? ~~Also, I don't know why the initial emulated value of PCI_HEADER_TYPE is set to 0x80 but I will assume that is the correct emulated value that should be exposed to the guest.~~ Update: After doing some research, I discovered the bit that is set in the PCI_HEADER_TYPE register (0x80) because of this issue is the bit to define the device as a multifunction device. None of my devices are multifunction, and the fact that the multifunction bit is incorrectly set on my passed through devices because of this issue seems to have no effect on the operation of the device or the guest. Apparently the author of the code to initialize the PCI_HEADER_TYPE register planned to initialize every passed through device as a multifunction device, but is this needed? My testing indicates it is not needed on my system. + +I am referring to this code in hw/xen/xen_pt_config_init.c: + +``` +static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s, + XenPTRegInfo *reg, uint32_t real_offset, + uint32_t *data) +{ + /* read PCI_HEADER_TYPE */ + *data = reg->init_val | 0x80; + return 0; +} + +[...] + + /* Header Type reg */ + { + .offset = PCI_HEADER_TYPE, + .size = 1, + .init_val = 0x00, + .ro_mask = 0xFF, + .emu_mask = 0x00, + .init = xen_pt_header_type_reg_init, + .u.b.read = xen_pt_byte_reg_read, + .u.b.write = xen_pt_byte_reg_write, + }, +``` +I would appreciate any guidance that experienced Qemu or Xen contributors can give me about this question. ~~If no one gives me any guidance here in a timely manner, I plan to propose my own fix officially to Qemu as the QubesOS patch plus changing the emu_mask value of the PCI_HEADER_TYPE register from 0x00 to 0x80. I verified that fixes the problem I am seeing in the PCI_STATUS register without also causing the change that the QubesOS patch makes to the PCI_HEADER_TYPE register.~~ + +I plan to submit a patch to fix this issue, noting the effect the patch has on the PCI_HEADER_TYPE register in the commit message. diff --git a/results/classifier/accel-gemma3:12b/vmm/1061778 b/results/classifier/accel-gemma3:12b/vmm/1061778 new file mode 100644 index 000000000..4faec5e58 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1061778 @@ -0,0 +1,10 @@ + +signal mask not reset on exec + +Seen in qemu-1.0 under 12.04, but AFAICT from current git it hasn't changed. + +./main-loop.c:qemu_signal_init blocks SIGALRM so it can be handled via signalfd. + +./net/tap.c:launch_script does not reset the signal mask before the execv() call, and signal masks are inherited. So the script is run with SIGALRM blocked (as can be seen in /proc/$$/status, "SigBlk: 0000000000002000"). One reasonable example of where this bites is an interface up script that calls ping with a timeout to give things a chance to settle down before continuing, but abort if this doesn't happen within a reasonable time). Since ping uses SIGALRM for the timeout, this now never terminates. + +qemu-0.14 didn't block SIGALRM, so such scripts worked fine there. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1064631 b/results/classifier/accel-gemma3:12b/vmm/1064631 new file mode 100644 index 000000000..1c917b501 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1064631 @@ -0,0 +1,14 @@ + +Feature request: tls for chardev socket (telnet,tcp,udp) + +Hello, + +it would be nice if chardev socket (telnet,tcp,udp) could have tls support as vnc does. + +This way we could have encrypted access to virtual character devices over network, +for example in setup: conserver -> socat+tls <-> qemu+chardev+tls. + +The best would be both direction - server even client, so even the client should +trust remote server (trustfile, fingeprint...?). + +Thank you. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1066 b/results/classifier/accel-gemma3:12b/vmm/1066 new file mode 100644 index 000000000..f62a6bf12 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1066 @@ -0,0 +1,33 @@ + +virtfs fails to access contents of non-readable directories +Description of problem: +Attempting to access a directory inside a non-readable directory via virtfs fails. +Steps to reproduce: +On host: +1. `mkdir -p test/foo/bar` +2. `echo hello world >test/foo/bar/baz.txt` +3. `chmod -r test/foo` + +The following works on host: + +``` +$ ls test +foo +$ ls test/foo +ls: cannot open directory 'test/foo': Permission denied +$ ls test/foo/bar +baz.txt +``` + +However on guest: + +``` +bash-5.1# ls /test/ +foo +bash-5.1# ls /test/foo/ +ls: cannot open directory '/test/foo/': Permission denied +bash-5.1# ls /test/foo/bar/ +ls: cannot access '/test/foo/bar/': Permission denied +``` +Additional information: +I am guessing virtfs attempts to check rights (via access?) on the directory itself when obtaining an inode to give to the guest, however not having read access doesn't mean something can't be executed, especially for directories. diff --git a/results/classifier/accel-gemma3:12b/vmm/1070762 b/results/classifier/accel-gemma3:12b/vmm/1070762 new file mode 100644 index 000000000..46c7d6221 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1070762 @@ -0,0 +1,38 @@ + +savevm fails with inserted CD, "Device '%s' is writable but does not support snapshots." + +Hi, + +yesterday unfortunately a customer reported a failed snapshot of his VM. Going through the logfile I discovered: + +"Device 'ide1-cd0' is writable but does not support snapshots" + +this is with qemu-1.2.0 and 1.0.1 at least... + +Why writeable? +Even if I specify "-drive ...,readonly=on,snapshot=off" to qemu the monitor-command sees the CD-ROM-device as being writeable?! + +Somewhere I saw a "hint" for blockdev.c: +=== snip === + +--- /tmp/blockdev.c 2012-10-24 11:37:10.000000000 +0200 ++++ blockdev.c 2012-10-24 11:37:17.000000000 +0200 +@@ -551,6 +551,7 @@ + case IF_XEN: + case IF_NONE: + dinfo->media_cd = media == MEDIA_CDROM; ++ dinfo->bdrv->read_only = 1; + break; + case IF_SD: + case IF_FLOPPY: + +=== snap === + +after installing with this small patch applied it works, so insert CD, savevm <somename> succeeds. +This should be fixed at all correct places, and the tags "readonly=on,snapshot=off" should do it, too. Or even just work after specifying a drive being a CD-rom should do the trick ;-) + +Another "bad habit" is, that the ISO/DVD-file has to be writeable to be changed? + +Thnx for attention and regards, + +Oliver. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1073 b/results/classifier/accel-gemma3:12b/vmm/1073 new file mode 100644 index 000000000..c5dae0a9c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1073 @@ -0,0 +1,30 @@ + +SIGABRT with -M raspi3b,accel=hvf on macOS +Description of problem: +There is a `SIGUSR2` or `SIGUSR1` raised which causes QEMU to abort: +``` +(lldb) bt +* thread #3, stop reason = signal SIGUSR2 + * frame #0: 0x0000000184c384a4 libsystem_kernel.dylib`__sigsuspend + 8 + frame #1: 0x0000000100b7ff34 qemu-system-aarch64`qemu_coroutine_new at coroutine-sigaltstack.c:221:9 + frame #2: 0x0000000100b91f0c qemu-system-aarch64`qemu_coroutine_create(entry=(qemu-system-aarch64`monitor_qmp_dispatcher_co at qmp.c:211), opaque=0x0000000000000000) at qemu-coroutine.c:90:14 + frame #3: 0x0000000100a833d8 qemu-system-aarch64`monitor_init_globals_core at monitor.c:707:25 +``` + +I tried skipping over it with `lldb`: +``` +(lldb) b main +(lldb) r +(lldb) process handle SIGUSR1 -s false -p true +(lldb) process handle SIGUSR2 -s false -p true +(lldb) c +qemu-system-aarch64: Unknown Error +``` + +I investigated the Unknown Error and and it's actually `HV_ILLEGAL_GUEST_STATE` which is unhandled in the `assert_hvf_ok` function. From here the VM will fail. +Steps to reproduce: +1. Get a fake disk. Or create a fake one with: `qemu-img create -f qcow2 zero.qcow2 2G` +2. Run QEMU with the HVF accelerator: `qemu-system-aarch64 -M raspi3b,accel=hvf -drive id=card0,if=none,format=qcow2,index=0,file=./zero.qcow2 -device sd-card,drive=card0 -serial stdio +` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1076 b/results/classifier/accel-gemma3:12b/vmm/1076 new file mode 100644 index 000000000..0dc6f6da1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1076 @@ -0,0 +1,13 @@ + +AC97+DirectSound only polls for audio every 10ms with no way to change it +Description of problem: +The AC97 device emulation, at least in combination with the DirectSound backend, only polls for audio every 10ms, meaning that DMA interrupts are received at a maximum frequency of 100Hz. This applies regardless of how large the buffers in the AC97's buffer list are, meaning that if one buffer takes less than 10ms to play, glitches can be heard with no possible mitigations on the host system. + +I came across this when fiddling with Serenity's own latencies in the AC97 driver and userland mixer. As soon as less than 512-sample buffers are used, audio becomes glitchy. Based on timing tests, kernel and userland processing of audio combined takes less than 200μs for one buffer, while the lowest average rate that DMA interrupts are received at is almost exactly 10ms. + +No changes to the dsound latency option, as listed [here](https://www.qemu.org/docs/master/system/invocation.html?highlight=dsound), made any difference; I tried as low as 2ms: `-audiodev dsound,id=snd0,latency=2000`. As far as I can tell there are no IRQ- or latency-related options for the AC97 emulation. +Steps to reproduce: +1. Use SerenityOS as of the above commit. +2. Before building, include an audio file in Base/home/anon; most ordinary FLAC, WAV and MP3 files created without options with ffmpeg should work. +3. Boot Serenity in QEMU on Windows without any special run configuration. +4. Play the audio file with `aplay <filename>`, hear glitches. diff --git a/results/classifier/accel-gemma3:12b/vmm/1077806 b/results/classifier/accel-gemma3:12b/vmm/1077806 new file mode 100644 index 000000000..44ce0d20f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1077806 @@ -0,0 +1,8 @@ + +Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request) + +I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea: + +What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop. + +I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/108 b/results/classifier/accel-gemma3:12b/vmm/108 new file mode 100644 index 000000000..724c90254 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/108 @@ -0,0 +1,2 @@ + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 diff --git a/results/classifier/accel-gemma3:12b/vmm/1087974 b/results/classifier/accel-gemma3:12b/vmm/1087974 new file mode 100644 index 000000000..3331111be --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1087974 @@ -0,0 +1,5 @@ + +[regression] vnc tight png produces garbled output + +VNC Tight PNG compression did work fine two or three month ago but don't anymore. Now when Tight PNG is used parts of the desktop are shown but they are scrambled together. +I have always tested this feature against QEMU git with noVNC by only allowing Tight PNG compression. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1089 b/results/classifier/accel-gemma3:12b/vmm/1089 new file mode 100644 index 000000000..d2784da04 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1089 @@ -0,0 +1,25 @@ + +when I use memory balloon,the qemu process memory usage is displayed incorrectly +Description of problem: +My vm memory is 4GB,and use the balloon driver,the balloon value is also 4GB. +I run a soft to consume memory in vm,I can see the memory usage rate is 15% in host. When I stop the soft in vm,the memory of free info in host and vm +become normal,but use "top -d 3 -Hp $qemu_pid" to query in host,the memory usage rate is also 15%.I need to modify the balloon value in a smaller values,the memory usage rate will reduce. why? + +Steps to reproduce: +1.run a soft to consume memory in vm,and query top info,the qemu process memory usage:15% + + +2.query free info in host and vm (reduce) + + +3.stop sort in vm + + +4.query free info in host and vm (recover) + + +5.query top info again (also 15%) + + + +6.modify the balloon value in a smaller (modify the balloon value in a smaller values,the memory usage rate will reduce) diff --git a/results/classifier/accel-gemma3:12b/vmm/1089005 b/results/classifier/accel-gemma3:12b/vmm/1089005 new file mode 100644 index 000000000..f8155ec6b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1089005 @@ -0,0 +1,21 @@ + +Qemu does not shutdown with vnc enabled on OS X + +I am running OS X 10.8.2 and Qemu 1.3.50 from your git repository. + +Running + + qemu-system-i386 <image> + +works fine. I can quit the process using ctrl-c. + +When I try to use + + qemu-system-i386 -vnc :<port> <image> + +ctrl-c does nothing and I have to kill the process trough the activity monitor. +Furthermore terminating the process from my java program does not work either. +I have also posted a question on Stackoverflow: http://stackoverflow.com/questions/13798367/qemu-does-not-shutdown-with-vnc-enabled-on-os-x + +Thanks +Leander \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1089006 b/results/classifier/accel-gemma3:12b/vmm/1089006 new file mode 100644 index 000000000..15b39558c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1089006 @@ -0,0 +1,12 @@ + +Qemu scrambles order of eth devices in vm + +HV = 12.04 LTS plus libvirt 1.0x +VM = 12.04 LTS + +On the HV there are 12 eth interfaces which we make available to the VM. We have 4 10G virtual function interfaces, and 8 1G conventionally bridged interfaces. No matter what order we present the interfaces in the xml file, they come up in eth0-eth11 order on the VM as follows: ( the interfcaes do work, once you figure out which is which) + +eth0-eth7 not in order as compoared to the bridges on the HV (interfaces file) or compared to the xml file for the VM, or compared to the bus numbers. MAC addresses are random. +eth8-eth11 show up in the VM in order of PCU bus numbers just as you'd expect, always after the bridged interfaces. + +Consulting the libvirt mailing list, the developer says they present the list in bus order to qemu, but qemu scrambles that order. That appears to me too, to be the case. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1090602 b/results/classifier/accel-gemma3:12b/vmm/1090602 new file mode 100644 index 000000000..ada18d388 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1090602 @@ -0,0 +1,12 @@ + +RFE: Allow specifying usb-host device by serial number + +Currently you can pass through a host USB device to the guest like + + -device usb-host,vendorid=0x1234,productid=0x5678 + +Which is all well and good, but has problems if you are trying to assign to identical USB devices to the same guest. + +It would be useful if there was an additional option that allow matching against the device's serial number, which should allow differentiating between two devices with the same product+vendor. + +This was originally filed at https://bugzilla.redhat.com/show_bug.cgi?id=640332 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1090604 b/results/classifier/accel-gemma3:12b/vmm/1090604 new file mode 100644 index 000000000..a92ab6da8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1090604 @@ -0,0 +1,12 @@ + +RFE: Implement support for SMBIOS Type 41 structures + +This was originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=669955 + +""" +Please extend the existing support for SMBIOS in qemu to add a capability to provide "Onboard Devices Extended Information" (Type 41). Not only is this replacing one of the existing types, but it also provides a mapping between devices and physical system chassis locations. But there is no physical chassis! Right. However, this doesn't mean you don't want to tell the guest OS which virtual (e.g. network) interface is which. You can do that, if you implement this extension that is already going into real hardware, and likely other VMs too. + +See also page 117 of the v2.7 of the SMBIOS spec. + +FWIW, VMware ESX and Workstation expose their PCI NICs in the PCI IRQ Routing Table. Kind of odd the first time you see it with biosdevname, as your NIC becomes pci3#1, but that's "correct" from a BIOS perspective. :-) +""" \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1091 b/results/classifier/accel-gemma3:12b/vmm/1091 new file mode 100644 index 000000000..2b1e71841 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1091 @@ -0,0 +1,14 @@ + +qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac +Description of problem: +The QEMU process hard crashes after a few minutes. The only message is: + +``` +vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed +``` +Steps to reproduce: +1. Run QEMU with the above commandline +2. Do something to keep the VM busy - running `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` reliably crashes it for me +3. Wait a 3-5 minutes +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1094 b/results/classifier/accel-gemma3:12b/vmm/1094 new file mode 100644 index 000000000..90084f7d9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1099 b/results/classifier/accel-gemma3:12b/vmm/1099 new file mode 100644 index 000000000..b1b8ec9b3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1099 @@ -0,0 +1,2 @@ + +zlib: Concurrent modification is unsafe diff --git a/results/classifier/accel-gemma3:12b/vmm/1103868 b/results/classifier/accel-gemma3:12b/vmm/1103868 new file mode 100644 index 000000000..39396747c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1103868 @@ -0,0 +1,47 @@ + +drive_mirror crashes on full disk copy of a resized disk with a backing file + +This bug was discovered using libvirt on ubuntu with a build of qemu 1.3 but it is trivailly reproducible with the curent git version. + +Repro steps: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-img resize /home/vishvananda/disk 64M +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio +QEMU 1.3.0 monitor - type 'help' for more information +(qemu) drive_mirror -f vda test +Formatting 'test', fmt=qcow2 size=67108864 encryption=off cluster_size=65536 lazy_refcounts=off +qemu-system-x86_64: /build/buildd/qemu-1.3.0+dfsg/block/mirror.c:129: mirror_run: Assertion `n > 0' failed. +Aborted + +Note that the command works just fine if the front image is not resized: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio + +or if the backing file is resized as well: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-img resize /home/vishvananda/disk 64M +qemu-img resize /home/vishvananda/base 64M +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio + +or if we don't use -f when creating the mirror: + +QEMU 1.3.0 monitor - type 'help' for more information +(qemu) drive_mirror vda test +Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off + +although in this final case the mirror is created the same size as the backing file which seems wrong: + +qemu-img info test +image: test +file format: qcow2 +virtual size: 32M (33554432 bytes) +disk size: 196K +cluster_size: 65536 +backing file: base +backing file format: qcow2 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1105670 b/results/classifier/accel-gemma3:12b/vmm/1105670 new file mode 100644 index 000000000..715ba39da --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1105670 @@ -0,0 +1,47 @@ + +Converting vpc image to raw results in an image that is smaller than it should be. + +When using qemu-img to convert a 3GB dynamic vhd image to raw, the resultant image was smaller than what I was expecting. I was expecting a new raw image of size 3221225472bytes but the size generated was 3220955136bytes. I had similar results when I used a fixed vhd image and explicitly specified the format as vpc. + +Details about my configuration +OS: Centos 5.4, 64bit +Qemu used 1.1.1-1, but also saw the same behavior on 1.3.3 and the development build. + +Command used for dynamic vhd image file: +qemu-img convert -O raw inputDynamic.vhd outputFromDynamic.raw + +Command used for fixed vhd image file: +qemu-img convert f vpc -O raw inputFixed.vhd outputFromFixed.raw + +Both images were first created on hyperv running on windows 2008 r2 using the hyperv manager interface. I think I tried their diskpart utility and had the same results. + +Output from the following commands (I saw this on Bug#893956) +$ hexdump -C -n 512 image.VHD +00000000 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| +00000010 00 00 00 00 00 00 02 00 18 25 da 57 77 69 6e 20 |.........%.Wwin | +00000020 00 06 00 01 57 69 32 6b 00 00 00 00 c0 00 00 00 |....Wi2k........| +00000030 00 00 00 00 c0 00 00 00 18 61 10 3f 00 00 00 03 |.........a.?....| +00000040 ff ff ee b1 83 34 83 78 26 0a 13 4f 99 9c 9e e9 |.....4.x&..O....| +00000050 dc 93 21 d1 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............| +00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +00000200 + +$ hexdump -C -n 512 -s $(($(ls -l image.VHD | awk '{ print $5 }') - 512)) image.VHD +56057e00 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| +56057e10 00 00 00 00 00 00 02 00 18 25 da 57 77 69 6e 20 |.........%.Wwin | +56057e20 00 06 00 01 57 69 32 6b 00 00 00 00 c0 00 00 00 |....Wi2k........| +56057e30 00 00 00 00 c0 00 00 00 18 61 10 3f 00 00 00 03 |.........a.?....| +56057e40 ff ff ee b1 83 34 83 78 26 0a 13 4f 99 9c 9e e9 |.....4.x&..O....| +56057e50 dc 93 21 d1 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............| +56057e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +56058000 +----- +When I investigated this a bit further I found that the disk geometry calculations needed to be one cylinder more than the information stored in the footer size information. The disk size information in the file was 3221225472 bytes, and the disk geometry was cylinders 6241, heads 10, sectors per cylinder 63. Multiplying that together and with a sector size of 512 gives 3220955136bytes...the size qemu made the image as, but the new image is now smaller than the original image. + +When I added one to the cylinder size I got a size larger than I was expecting, but large enough to hold all of the data from the original image. + +My suggested fix for this is to add one to the cylinder size when reading a vhd image file. And subtracting one when writing out to a vhd file. I've attached a patch with the suggested fix. + +Please let me know if you need additional information. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1113 b/results/classifier/accel-gemma3:12b/vmm/1113 new file mode 100644 index 000000000..81c73cd24 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1113 @@ -0,0 +1,15 @@ + +TMPDIR is not usable for snapshot-blockdevs, if not root +Description of problem: +for using static disk-content we're using `snapshot`-flag for certain disks and set `TMPDIR` to a VM-specific path. + +when started as root, all is ok. + +when started as non-root, `getenv(TMPDIR)` in function `get_tmp_filename()` in file `block.c` return `NULL`, because glibc handles `TMPDIR` as `UNSECURE_ENVVAR` (glibc-src: `sysdeps/generic/unsecvars.h`) + +well, we could compile qemu by ourself, but then we might miss important updates, so maybe this can be solved in main-source? + +possible solutions: +- additionally look at another var like `QEMU_TMPDIR`, if `getenv("TMPDIR")` results in `NULL` +- add a global option to qemu like `--tmpdir=...` +- add a device-specific option like `snapshotdir=...` diff --git a/results/classifier/accel-gemma3:12b/vmm/1114 b/results/classifier/accel-gemma3:12b/vmm/1114 new file mode 100644 index 000000000..b82724956 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1114 @@ -0,0 +1,2 @@ + +Non-deterministic hang in libvfio-user:functional/test-client-server test causing timeout in CentOS 8 CI job diff --git a/results/classifier/accel-gemma3:12b/vmm/1117 b/results/classifier/accel-gemma3:12b/vmm/1117 new file mode 100644 index 000000000..f7291ce46 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1117 @@ -0,0 +1,96 @@ + +migration corrupts qcow2 metadata when "backing file: json:{" is involve +Description of problem: +the bug happens when you have a qcow2 with backing file in json format +image: 2.qcow2 +[...] +backing file: json:{"driver": "qcow2", "file": { "driver": "file", "filename": "1.qcow2"}} +backing file format: qcow2 +[...] +if you want to migrate a VM that have that kind of qcow2 attached, the migration is gonna corrupted qcow2 metadata in memory and info block will look like this +json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} +later if you execute blockdev-snapshot-sync, the corrupt json will be write to the new qcow2 resulting with a unusable qcow2 +Steps to reproduce: +/opt/qemu-7.0.0/bin/qemu-img create -f qcow2 0.qcow2 64G +/opt/qemu-7.0.0/bin/qemu-img create -F qcow2 -f qcow2 -b 'json:{"driver": "qcow2", "file": { "driver": "file", "filename": "0.qcow2"}}' 1.qcow2 +/opt/qemu-7.0.0/bin/qemu-img create -F qcow2 -f qcow2 -b 'json:{"driver": "qcow2", "file": { "driver": "file", "filename": "1.qcow2"}}' 2.qcow2 + +#VM1 +/opt/qemu-7.0.0/bin/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=2.qcow2,node-name=drive0 -qmp stdio -display none + +#VM2 +/opt/qemu-7.0.0/bin/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=2.qcow2,node-name=drive0 -qmp stdio -display none -incoming tcp::8082 + + +#VM1 INFO BLOCK +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 7}, "package": ""}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0): 2.qcow2 (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writethrough\r\n Backing file: 1.qcow2 (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + +#VM1 MIGRATE +{ "execute": "migrate", "arguments": { "uri": "tcp:localhost:8082" } } +{"return": {}} +{"timestamp": {"seconds": 1658491019, "microseconds": 233177}, "event": "STOP"} + + +#VM2 INFO BLOCK +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 7}, "package": ""}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0): 2.qcow2 (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writeback\r\n Backing file: 1.qcow2 (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + +#VM2 MIGRATE +{"timestamp": {"seconds": 1658491019, "microseconds": 249760}, "event": "RESUME"} + +#VM2 MIGRATION DONE, INFO BLOCK +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0): json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writethrough\r\n Backing file: json:{\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}} (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + + +#VM2 SNAPSHOT AFTER MIGRATION +{ "execute": "blockdev-snapshot-sync", "arguments": { "format": "qcow2", "snapshot-file": "3.qcow2", "node-name": "drive0", "snapshot-node-name": "drive0-snap" }} +Formatting '3.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=68719476736 backing_file=json:{"backing": {"backing": {"driver": "qcow2",, "file": {"driver": "file",, "filename": "0.qcow2"}},, "driver": "qcow2",, "file": {"driver": "file",, "filename": "1.qcow2"}},, "driver": "qcow2",, "file": {"driver": "file",, "filename": "2.qcow2"}} backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16 +{"return": {}} + + +#VM2 INFO BLOCK AFTER SNAPSHOT +{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} } +{"return": "virtio0 (drive0-snap): 3.qcow2 (qcow2)\r\n Attached to: /machine/peripheral-anon/device[0]/virtio-backend\r\n Cache mode: writethrough\r\n Backing file: json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} (chain depth: 3)\r\n\r\nide1-cd0: [not inserted]\r\n Attached to: /machine/unattached/device[24]\r\n Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n Attached to: /machine/unattached/device[17]\r\n Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n Removable device: not locked, tray closed\r\n"} + + + +#INFO +/opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2 +qemu-img: Could not open 'json:{"backing": {"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "0.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "1.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "2.qcow2"}}': Block format 'qcow2' does not support the option 'backing.backing.driver' +Additional information: +Even if the bug is scary it's very simple to fix it + +/opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2 +qemu-img: Could not open 'json:{"backing": {"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "0.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "1.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "2.qcow2"}}': Block format 'qcow2' does not support the option 'backing.backing.driver' + +root@lenovo2:/data# /opt/qemu-7.0.0/bin/qemu-img rebase -f qcow2 -F qcow2 -u -b 2.qcow2 3.qcow2 +root@lenovo2:/data# /opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2 +image: 3.qcow2 +file format: qcow2 +virtual size: 64 GiB (68719476736 bytes) +disk size: 24 KiB +cluster_size: 65536 +backing file: 2.qcow2 +backing file format: qcow2 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false + +image: 2.qcow2 +file format: qcow2 +virtual size: 64 GiB (68719476736 bytes) +disk size: 24 KiB +cluster_size: 65536 +[..........] diff --git a/results/classifier/accel-gemma3:12b/vmm/1119281 b/results/classifier/accel-gemma3:12b/vmm/1119281 new file mode 100644 index 000000000..5a46af04c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1119281 @@ -0,0 +1,36 @@ + +The virtio network device breaks UuidCreateSequential() + +UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue. + +Here is the software I have tested this with: + * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) + * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. + + +Here is how to test for this issue: +* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. + +* Boot the guest and copy the uuidtest.exe file (see attachement) to it + +* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below: + + Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 + +* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0. + + UuidCreateSequential() returned 0 + uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} + Got a version 1 UUID + The UUID does not contain a non-multicast MAC address + +* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be. + +* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address. + + +(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +(2) Best do it with a single card to avoid confusion over which is the primary one. +(3) If the first byte of the address is odd then this is a multicast address. + https://en.wikipedia.org/wiki/MAC_address#Address_details \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1119861 b/results/classifier/accel-gemma3:12b/vmm/1119861 new file mode 100644 index 000000000..79aae87cc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1119861 @@ -0,0 +1,20 @@ + +Poor console performance in Windows 7 + +As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: + + 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver + 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver +127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver +127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver +147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver +145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) + + 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver + 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver + 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver + 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver + +So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. + +Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/113 b/results/classifier/accel-gemma3:12b/vmm/113 new file mode 100644 index 000000000..95e0d2841 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/113 @@ -0,0 +1,2 @@ + +missing manpage for bridge.conf diff --git a/results/classifier/accel-gemma3:12b/vmm/1136477 b/results/classifier/accel-gemma3:12b/vmm/1136477 new file mode 100644 index 000000000..0afc107a8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1136477 @@ -0,0 +1,6 @@ + +qemu doesn't sanitize command line options carrying plaintext passwords + +A slight security problem exists with qemu's lack of sanitization of argv[], for cases where the user may have specified a plaintext password for spice/vnc authorization. (Yes, it's not great to use this facility, but it's convenient and not grotesquely unsafe, were it not for this bug.) It would be nice if those plaintext passwords were nuked from the command line, so a subsequent "ps awux" didn't show them for all to see. + +See also https://bugzilla.redhat.com/show_bug.cgi?id=916279 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1137 b/results/classifier/accel-gemma3:12b/vmm/1137 new file mode 100644 index 000000000..593ca121c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1137 @@ -0,0 +1,36 @@ + +When using qemu-system-x86_64 whpx acceleration, cpu information is set strangely. +Description of problem: +When using the guest with whpx acceleration in qemu-system-x86_64, the CPU information of the guest seems to be set strangely. + +When the guest is Linux, it seems that individual CPUs are allocated as many as the number of cores when using the -accel whpx option and the -smp option. +* -smp 4, -smp cores=4, -smp sockes=1, cores=4, threads=1 are all set to have 4 single-core CPUs plugged in + +If the guest is Windows, check the information with CPU-Z + It is recognized as a Pentium 4 and is displayed as a CPU with 1 core and n threads. + +Physically, it seems to be set to have n individual CPUs with 1 core plugged in. +In Windows 11 Home (which seems to be the case for all versions of Windows Home), you cannot give the -smp value more than 5. +* When booting with the -smp option value of 5 or more, a BSOD saying multiprocessor configuration not supported appears. -smp n, -smp cores=n, -smp sockes=1,cores=n,threads=1 All same symptoms occur +Steps to reproduce: +1. Boot Windows or Linux with -accel whpx -smp 4 option (or with the -accel whpx -smp sockets=1,cores=4,threads=1 option to make it deterministic) +2. For Linux guest, use cat /proc/cpuinfo to check cpu information, for Windows guest, use cpu-z, device manager, task manager, etc. to check cpu information +3. In the information of the Linux guest, it is displayed as fixed as core id : 0, cpu cores : 1, + In Windows guest, information is displayed as written in "Description of problem" respectively. +Additional information: +**Windows 11 Home Guest set to 4 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + + + +**Windows 11 Home Guest set to 5 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=5,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + + + +**Linux (Debian 11) guest set to 4 cores :** + +qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 4g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="debian.vdi",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx + diff --git a/results/classifier/accel-gemma3:12b/vmm/1152 b/results/classifier/accel-gemma3:12b/vmm/1152 new file mode 100644 index 000000000..e449acecd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1152 @@ -0,0 +1,29 @@ + +Windows crashes on resuming from sleep if hv-tlbflush is enabled +Description of problem: +The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case). +Steps to reproduce: +1. Boot Windows +2. Tell Windows to go to sleep (observe that qemu's state switches to suspended) +3. Cause windows to wake up (e.g. using the `system_wakeup` HMP command) +Additional information: +Looking at the crash dumps always shows the "ATTEMPTED WRITE TO READONLY MEMORY" error, and always with this stack trace: + +``` +nt!KeBugCheckEx +nt!MiRaisedIrqlFault+0x1413a6 +nt!MmAccessFault+0x4ef +nt!KiPageFault+0x35e +nt!MiIncreaseUsedPtesCount+0x12 +nt!MiBuildForkPte+0xc6 +nt!MiCloneVads+0x4ab +nt!MiCloneProcessAddressSpace+0x261 +nt!MmInitializeProcessAddressSpace+0x1cb631 +nt!PspAllocateProcess+0x1d13 +nt!PspCreateProcess+0x242 +nt!NtCreateProcessEx+0x85 +nt!KiSystemServiceCopyEnd+0x25 +ntdll!NtCreateProcessEx+0x14 +``` + +However, the process that is being created here is always `WerFault.exe`, i.e. the crash reporter. The crashing process is seemingly random. Removing `hv-tlbflush` from the command line resolves the problem. Hence, my hypothesis is that due to improper TLB flushing during wakeup, a random application on the core will crash, which spawns `WerFault.exe` which then immediately crashes again inside the kernel (also because of bad/stale TLB contents) and causes the BSOD. Perhaps one core wakes up first, requests a TLB flush, which is then *not* propagated to sleeping cores due to hv-tlbflush. Then one of those cores wakes up without the TLB flush? diff --git a/results/classifier/accel-gemma3:12b/vmm/1155677 b/results/classifier/accel-gemma3:12b/vmm/1155677 new file mode 100644 index 000000000..765e00060 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1155677 @@ -0,0 +1,23 @@ + +snapshot=on fails with non file-based storage + +The snapshot=on option doesn't work with an nbd block device: + +/usr/bin/qemu-system-x86_64 \ +[...] + -device virtio-scsi-pci,id=scsi \ + -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ +[...] + +gives the error: + +qemu-system-x86_64: -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none: could not open disk image nbd:localhost:61930: No such file or directory + +If you remove the snapshot=on flag, it works (although that of course means that the block device is writable which we don't want). + +Previously reported here: + + http://permalink.gmane.org/gmane.comp.emulators.qemu/148390 + +and I can confirm this still happens in qemu 1.4.0. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1156632 b/results/classifier/accel-gemma3:12b/vmm/1156632 new file mode 100644 index 000000000..07b6c70aa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1156632 @@ -0,0 +1,25 @@ + +not receiving RESET event after system_reset command causes QMP connection to die + +I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection: + +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) close socket +7) Connect to socket -> connection refused + +However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events: +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) Receive reply (is a RESET event) +7) Receive reply (is a RESET event) +8) close socket +9) Connect to socket -> ok + +I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1157368 b/results/classifier/accel-gemma3:12b/vmm/1157368 new file mode 100644 index 000000000..afbaaefac --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1157368 @@ -0,0 +1,8 @@ + +Desktop background messed up when running Raring in a QEMU-based virtual machine + +Screenshot attached. + +Problem occurs only when choosing the default cirrus graphics card. The other graphics cards do not show this problem but are very unstable. + +The screenshot is of the whole desktop with a Virtual Machine Manager window containing the desktop of the VM. You see that its actual background is messed up and also the background images which you can choose when right-clicking the background and choosing "Change Desktop Background". \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1158 b/results/classifier/accel-gemma3:12b/vmm/1158 new file mode 100644 index 000000000..cc635463f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1158 @@ -0,0 +1,2 @@ + +Error in setting VNC password diff --git a/results/classifier/accel-gemma3:12b/vmm/1162227 b/results/classifier/accel-gemma3:12b/vmm/1162227 new file mode 100644 index 000000000..6a030f02c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1162227 @@ -0,0 +1,17 @@ + +Mouse works badly when connecting to host via vnc + +Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. +Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. + +I saw this bug in the following configurations: +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: +qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda +* A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow + +Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". + +Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1163034 b/results/classifier/accel-gemma3:12b/vmm/1163034 new file mode 100644 index 000000000..618eaaaa1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1163034 @@ -0,0 +1,9 @@ + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) + +Please look at +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+packages +and +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+build/4457434 + +I cannot make gnutls28 build on armhf, I suspect a builder problem \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1163065 b/results/classifier/accel-gemma3:12b/vmm/1163065 new file mode 100644 index 000000000..769b37871 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1163065 @@ -0,0 +1,19 @@ + +target-i386 cpu_get_phys_page_debug checks bits in wrong order + +In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked before CR0_PG. This means that if paging is disabled but the PAE bit has been set in CR4, cpu_get_phys_page_debug will return the wrong result (it will try to translate the address as virtual rather than using it as a physical address). + +Although this might seem like an unusual case, it in fact happens consistently when booting Linux on amd64 (from linux-2.6.32.60/arch/x86/boot/compressed/head_64.S): + + /* Enable PAE mode */ + xorl %eax, %eax + orl $(X86_CR4_PAE), %eax + movl %eax, %cr4 +[... code to set up page tables omitted ...] + /* Enter paged protected Mode, activating Long Mode */ + movl $(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected mode */ + movl %eax, %cr0 + +The most noticeable effect of this bug is that using the disassembler during this time will fetch the wrong data by trying to read from page tables that aren't there. One symptom is that booting Linux amd64 with -d in_asm will result in several "Disassembler disagrees with translator over instruction decoding" messages. + +Attached is a patch that moves the CR0_PG check to the beginning. I'm still not 100% certain that the logic of cpu_get_phys_page_debug matches cpu_x86_handle_mmu_fault, but it's a start. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1167 b/results/classifier/accel-gemma3:12b/vmm/1167 new file mode 100644 index 000000000..1fdc389d9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1167 @@ -0,0 +1,2 @@ + +Does qemu-system-aarch64 support hyper-v elightenment feature for windows for arm guest? diff --git a/results/classifier/accel-gemma3:12b/vmm/1168733 b/results/classifier/accel-gemma3:12b/vmm/1168733 new file mode 100644 index 000000000..b5bf5db90 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1168733 @@ -0,0 +1,12 @@ + +reserved identifier violation + +I would like to point out that identifiers like the following do not fit to the expected naming convention of the C language standard. +- __COMMAND_H__ + http://git.qemu.org/?p=qemu.git;a=blob;f=cmd.h;hb=64b85a8f2359ca3a995499afaf3c87d8e036e030#l17 + +- _QEMU_OPTIONS_H_ + http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.h;hb=77bd1119ba43dbd0e73014037a08f8b49136bf6f#l28 + +Would you like to adjust your selection for unique names? +https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier#DCL37-C.Donotdeclareordefineareservedidentifier-NoncompliantCodeExample%28HeaderGuard%29 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1176 b/results/classifier/accel-gemma3:12b/vmm/1176 new file mode 100644 index 000000000..749fb33ec --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1176 @@ -0,0 +1,8 @@ + +VVFAT :rw writes from guest (ReactOS, windowsXP) not visible by host +Description of problem: +As described in https://jira.reactos.org/browse/CORE-18327 +While ./LMS is mounted as a :rw VVFAT drive, guest OS (ReactOS) is able to read files BUT when files are "written" from the guest, they are not visible on host side. +QEMU execution is also massively polluted by "invalid file name" messages coming from https://git.qemu.org/?p=qemu.git;a=blob_plain;f=block/vvfat.c;hb=HEAD (but this is not specific to the use with ReactOS, as this is also observed with other guest : WXP, ...) + +See attached screenshot showing WXPSP3 as guest with file created in VVFAT drive while guest misses the newly created file. diff --git a/results/classifier/accel-gemma3:12b/vmm/1179664 b/results/classifier/accel-gemma3:12b/vmm/1179664 new file mode 100644 index 000000000..dab56c038 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1179664 @@ -0,0 +1,16 @@ + +migration.c:293: undefined reference to `__sync_val_compare_and_swap_4' + +latest git qemu error i get on compiling with mingw + + LINK i386-softmmu/qemu-system-i386w.exe +../migration.o: In function `migrate_finish_set_state': +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +collect2.exe: error: ld returned 1 exit status +make[1]: *** [qemu-system-i386w.exe] Error 1 +make: *** [subdir-i386-softmmu] Error 2 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1181796 b/results/classifier/accel-gemma3:12b/vmm/1181796 new file mode 100644 index 000000000..09e596667 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1181796 @@ -0,0 +1,10 @@ + +Qemu locks up when incoming serial fills up + +I'm using Windows, I'm not sure if this happens on Linux, but for all I know it does. To repro, fire up any image (ideally one that does almost nothing, and doesn't read the serial port), and use the option "-serial pipe:mypipe". Then use Putty or something else to connect to that named pipe so Qemu starts up. Now start typing into Putty. For a VM image that never reads the serial port, upon typing the 16th character Qemu stops executing instructions in the guest (as evidenced either by being unable to step in gdb, seeing that "info registers" in the monitor always reports the same value, or just by observing that the guest is hung). For OS images that do regularly read the serial port, this may require pasting >16 bytes into Putty at once. This occurs with more than just Putty, use anything that can write at a named pipe. + +I would have expected that bytes get dropped, or even more ideally blocked at the sender's side of the named pipe. I would not expect that the entire VM stops. You seem to be able to unwedge the VM by switching to the monitor and running "i /1c 0x3f8" until you've pulled enough out of buffer that it's happy to run again. Interestingly, all bytes seem to come through (more than just the 16) when read from the monitor. + +I haven't been able to get a source environment set up, but I have tried a few of the Windows binaries. This repros in 1.4.1, 1.3.0, 1.2, and 1.0, the most recent build I found that did not have this behavior was 0.15.0. + +Maybe I'm missing something very obvious, and if so, I apologize in advance. I'm also happy to create an OS image that highlights this problem if it would help. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1185395 b/results/classifier/accel-gemma3:12b/vmm/1185395 new file mode 100644 index 000000000..c1898c1fe --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1185395 @@ -0,0 +1,13 @@ + +qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend + +With a running VM I encounter this strange behaviour, former qemu-versions don't show up such an error. +Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with ceph-0.56.6? + +( -95 might be a general "Operation not supported" error? ) + +Up to 1.4.2 everything is OK with savevm, though. + +Any help welcome, + +Oliver. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1187 b/results/classifier/accel-gemma3:12b/vmm/1187 new file mode 100644 index 000000000..13f7db86d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1187 @@ -0,0 +1,2 @@ + +can not handler real-time signal (signal number > 30) by sigqueue on linux user mode diff --git a/results/classifier/accel-gemma3:12b/vmm/1188 b/results/classifier/accel-gemma3:12b/vmm/1188 new file mode 100644 index 000000000..feff171b4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1188 @@ -0,0 +1,5 @@ + +qapi: add support to default value for optional members +Additional information: +This is a proposal to the QAPI spec itself to have a simple way to express that +an absent member defaults to a value. diff --git a/results/classifier/accel-gemma3:12b/vmm/1190525 b/results/classifier/accel-gemma3:12b/vmm/1190525 new file mode 100644 index 000000000..c557976a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1190525 @@ -0,0 +1,37 @@ + +fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk + +RHEL guest shows the partittions even after the removal of scsi disk: +fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. + +Guest details: +------------------- +Kernel : 2.6.32-358 + + +Host Details : + +Upstream Kernel, Qemu, Libvirt and virt-manager +--------------------------------------------------------------------- + +kernel version : 3.9.0+ +qemu version : QEMU emulator version 1.5.0 +libvirt version : 1.0.5 +virt-install : 0.600.3 + + +Steps to reproduce the issue: + +I. Add the SCSI disk through the virt-manager. +2. Create the partition using fdisk (eg: /dev/sbb) +3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 +4. Remove the scsi disk through the virt-manager. +5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. + +This issue is not seen with virt-io disk. + +This issue is also reproducible without even creating the partitions. + +Expected Result: + +The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1192065 b/results/classifier/accel-gemma3:12b/vmm/1192065 new file mode 100644 index 000000000..95be77b54 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1192065 @@ -0,0 +1,7 @@ + +qemu release memory to system + +Qemu pre-allocates the maximum balloon amount which is inconvinient if all of the memory is used up and some other system needs to be added memory resource + +eg:- I have 4GB RAM with 4 virtual systems to be run. +I want each of them to start with 1GB RAM with maximum 2GB possible. This is not achievable since qemu pre-allocates the maximum balloon amount which is 2GBx4 systems . So to start all 4 systems the system needs 8GB RAM rather than 4GB RAM to start with although I have told initial balloon amount to be 1GB. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1193 b/results/classifier/accel-gemma3:12b/vmm/1193 new file mode 100644 index 000000000..f560436b7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1193 @@ -0,0 +1,17 @@ + +io_uring / iothread regression 7.1.0 +Description of problem: +After upgrading to 7.1.0, some of my libvirt VM's failed to boot. I have narrowed down the issue to the combination of: + +- io_uring +- iothread +Steps to reproduce: +1. set up a VM with iothread and io_uring +2. try to boot and watch it "hang" +Additional information: +Here's the relevant command line from the libvirt log: +``` +-blockdev '{"driver":"file","filename":"/mnt/data/VMs/Arch-Linux-x86_64-basic.qcow2","aio":"io_uring","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-pci","iothread":"iothread1","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1 }' \ +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1193555 b/results/classifier/accel-gemma3:12b/vmm/1193555 new file mode 100644 index 000000000..eaeb2199f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1193555 @@ -0,0 +1,12 @@ + +Add scale options to window menu + +This is a workaround against bug #504368, which makes QEMU window text blurry if resized. This is a common and annoying problem: + +http://butnottoohard.blogspot.com/2010/01/qemukvm-windows-7-blurry-text.html +http://unix.stackexchange.com/questions/60564/how-can-i-restore-default-window-size-in-kvm-qemu + + +The ability to resize window is a feature - it allows to adjust viewport of QEMU to the convenient working area. But there should be an option to restore the size of the window or scale it like 1:2, 2:1 etc. I don't know about if that should be exposed to QEMU monitor as some "window <command>" set , but it would be extremely convenient to provide at least Ctrl+Alt+U functionality through window level menu. + +Ubuntu 13.04, QEMU 1.4.0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1193564 b/results/classifier/accel-gemma3:12b/vmm/1193564 new file mode 100644 index 000000000..2416f3eaf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1193564 @@ -0,0 +1,4 @@ + +monitor: rename `screendump` command to `screenshot` + +`screendump` is hard to memorize for occasional users. It is easier to remember `screenshot` name. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/120 b/results/classifier/accel-gemma3:12b/vmm/120 new file mode 100644 index 000000000..96468af9e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/120 @@ -0,0 +1,2 @@ + +Please provide an option to print the default hardware configuration as command-line options, to make -nodefaults easier to use diff --git a/results/classifier/accel-gemma3:12b/vmm/1201 b/results/classifier/accel-gemma3:12b/vmm/1201 new file mode 100644 index 000000000..1c2888c6b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1201 @@ -0,0 +1,11 @@ + +Qemu with Windows 10 +Description of problem: +I see a colored screen with flashing cursor and cannot complete Windows installation. +Steps to reproduce: +1. Install `qemu-w64-setup-20220831.exe` on Windows 10 Pro for Workstations 21H2. +2. `cd C:\Program Files\qemu` +3. `qemu-img.exe create -f raw win.img 25600M` +4. `qemu-system-i386w.exe -boot c -m 4096 -hda win.img -cdrom "C:\Users\me\Downloads\Win10_21H2_English_x64.iso"` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1207 b/results/classifier/accel-gemma3:12b/vmm/1207 new file mode 100644 index 000000000..86c1c238c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1207 @@ -0,0 +1,4 @@ + +Cannot use qcow2 to create a VM on apple silicon macbook +Description of problem: +Nothing to output when I input the command above. And it seems not to boot successfully. diff --git a/results/classifier/accel-gemma3:12b/vmm/1211910 b/results/classifier/accel-gemma3:12b/vmm/1211910 new file mode 100644 index 000000000..e79750866 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1211910 @@ -0,0 +1,9 @@ + +Logical to linear address translation is wrong for 32-bit guests on a 64-bit hypervisor + +I run a 64-bit hypervisor in qemu-system-x86_64 (without KVM) and on top of that I have a 32-bit guest. The guest configures the code-segment to have a base of 0x4000_0000 and a limit of 0xFFFF_FFFF with paging disabled. Thus, if a logical address of e.g. 0xC000_0000 is used, it should be translated to 0x0000_0000 (linear and physical), because of the overflow that happens. +But this does not happen with the described setup. Instead, qemu seems to calculate the logical to linear translation with 64-bit addresses so that no overflow happens. Consequently, the resulting address is 0x1_0000_0000 and this gets written to exitinfo2 in the VMCB structure. This causes trouble for hypervisors that expect the upper 32 bits of exitinfo2 to be 0 for 32-bit guests. + +Note also that the exact same setup runs fine on real AMD machines with SVM. That is, the upper 32 bits in exitinfo2 are always 0 because of the overflow. + +I've tested that with the latest development version of QEMU (commit 328465fd9f3a628ab320b5959d68d3d49df58fa6). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1214884 b/results/classifier/accel-gemma3:12b/vmm/1214884 new file mode 100644 index 000000000..ccabf5e27 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1214884 @@ -0,0 +1,10 @@ + +Support VDI (Virtualbox) snapshots + +Please support Snapshots in VDI images. + +It seems that VirtualBox uses a snapshot for any changes to the main system disc. Even when the user does not create a snapshot. + +So if I want to mount a VDI disc with the recent system changes, I have to mount the Snapshot. + +Thanks \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1215 b/results/classifier/accel-gemma3:12b/vmm/1215 new file mode 100644 index 000000000..6c99b4247 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1215 @@ -0,0 +1,73 @@ + +block-stream qmp command regression in 7.1.0 +Description of problem: +After `block-stream` qmp commands, guest was hanged when using `iothread` option. +According to b1e1af3, there are some change at drain blockdev subtree and strong reference to base node. +We couldn't produce this issue when we reverted the commit. +It seems to be raised by racing acquiring aio_lock between iothread and main thread. +Steps to reproduce: +1. Start Guest with upper command. +2. After started, operate `block-stream` command to qmp socket +``` +echo '{"execute":"qmp_capabilities"}{ + "execute":"block-stream", + "arguments":{ + "job-id":"hangTest", + "device":"vdaFile" + } +}' | sudo nc -U /var/run/monitor_a9b43742-9117-4aae-8887-24bdb017ec20 -N +``` +Additional information: +- gdb debug stack +``` +Thread 1 (Thread 0x7fcfaed84600 (LWP 162409) "qemu-system-x86"): +#0 0x00007fcfaf108e7e in __ppoll (fds=0x5634a9b6b240, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 +#1 0x00005634a7be22dd in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64 +#2 0x00005634a7bc02c9 in fdmon_poll_wait (ctx=0x5634a990eec0, ready_list=0x7ffcb2ce4fb8, timeout=-1) at ../util/fdmon-poll.c:80 +#3 0x00005634a7bbf9c9 in aio_poll (ctx=ctx@entry=0x5634a990eec0, blocking=blocking@entry=true) at ../util/aio-posix.c:660 +#4 0x00005634a7ac849d in bdrv_parent_drained_end_single (c=c@entry=0x5634a9b4bb30) at ../block/io.c:76 +#5 0x00005634a7a98240 in bdrv_replace_child_noperm (childp=0x5634a9b61240, new_bs=0x0, free_empty_child=<optimized out>) at ../block.c:2910 +#6 0x00005634a7a987fe in bdrv_replace_child_tran (childp=<optimized out>, new_bs=<optimized out>, tran=<optimized out>, free_empty_child=<optimized out>) at ../block.c:2444 +#7 0x00005634a7a988bc in bdrv_remove_file_or_backing_child (bs=bs@entry=0x5634a9b5d1f0, child=child@entry=0x5634a9b4bb30, tran=tran@entry=0x5634aa415fc0) at ../block.c:5155 +#8 0x00005634a7a9fac6 in bdrv_remove_file_or_backing_child (tran=0x5634aa415fc0, child=0x5634a9b4bb30, bs=0x5634a9b5d1f0) at ../block.c:5133 +#9 bdrv_set_file_or_backing_noperm (parent_bs=parent_bs@entry=0x5634a9b5d1f0, child_bs=child_bs@entry=0x0, is_backing=is_backing@entry=true, tran=tran@entry=0x5634aa415fc0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3412 +#10 0x00005634a7a9fd04 in bdrv_set_backing_noperm (errp=0x7ffcb2ce5150, tran=0x5634aa415fc0, backing_hd=0x0, bs=0x5634a9b5d1f0) at ../block.c:3449 +#11 bdrv_set_backing_hd (bs=bs@entry=0x5634a9b5d1f0, backing_hd=backing_hd@entry=0x0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3461 +#12 0x00005634a7b25e19 in stream_prepare (job=0x5634a9e83da0) at ../block/stream.c:85 +#13 0x00005634a7aa922e in job_prepare (job=0x5634a9e83da0) at ../job.c:837 +#14 job_txn_apply (fn=<optimized out>, job=0x5634a9e83da0) at ../job.c:158 +#15 job_do_finalize (job=0x5634a9e83da0) at ../job.c:854 +#16 0x00005634a7aa9726 in job_exit (opaque=0x5634a9e83da0) at ../job.c:941 +#17 0x00005634a7bd26b4 in aio_bh_call (bh=0x7fcfa0824010) at ../util/async.c:150 +#18 aio_bh_poll (ctx=ctx@entry=0x5634a990eec0) at ../util/async.c:178 +#19 0x00005634a7bbf602 in aio_dispatch (ctx=0x5634a990eec0) at ../util/aio-posix.c:421 +#20 0x00005634a7bd22f2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320 +#21 0x00007fcfaf3c0d1b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x00005634a7bde7c0 in glib_pollfds_poll () at ../util/main-loop.c:297 +#23 os_host_main_loop_wait (timeout=114194793) at ../util/main-loop.c:320 +#24 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596 +#25 0x00005634a784fdc3 in qemu_main_loop () at ../softmmu/runstate.c:734 +#26 0x00005634a769f9e0 in qemu_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:38 +--Type <RET> for more, q to quit, c to continue without paging-- +#27 0x00007fcfaf019d90 in __libc_start_call_main (main=main@entry=0x5634a769b0c0 <main>, argc=argc@entry=56, argv=argv@entry=0x7ffcb2ce54c8) at ../sysdeps/nptl/libc_start_call_main.h:58 +#28 0x00007fcfaf019e40 in __libc_start_main_impl (main=0x5634a769b0c0 <main>, argc=56, argv=0x7ffcb2ce54c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb2ce54b8) at ../csu/libc-start.c:392 +#29 0x00005634a769f905 in _start () +``` +- iothread gdb stack +``` +Thread 3 (Thread 0x7fcfae47e640 (LWP 162411) "IO iothread1"): +#0 futex_wait (private=0, expected=2, futex_word=0x5634a9b49620) at ../sysdeps/nptl/futex-internal.h:146 +#1 __GI___lll_lock_wait (futex=futex@entry=0x5634a9b49620, private=0) at ./nptl/lowlevellock.c:49 +#2 0x00007fcfaf0880dd in lll_mutex_lock_optimized (mutex=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:48 +#3 ___pthread_mutex_lock (mutex=mutex@entry=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:128 +#4 0x00005634a7bc25b8 in qemu_mutex_lock_impl (mutex=0x5634a9b49620, file=0x5634a7da2997 "../util/async.c", line=682) at ../util/qemu-thread-posix.c:88 +#5 0x00005634a7bd24a5 in aio_context_acquire (ctx=0x5634a9b495c0) at ../util/async.c:682 +#6 co_schedule_bh_cb (opaque=0x5634a9b495c0) at ../util/async.c:520 +#7 0x00005634a7bd26b4 in aio_bh_call (bh=0x5634a9b494a0) at ../util/async.c:150 +#8 aio_bh_poll (ctx=ctx@entry=0x5634a9b495c0) at ../util/async.c:178 +#9 0x00005634a7bbf754 in aio_poll (ctx=0x5634a9b495c0, blocking=blocking@entry=true) at ../util/aio-posix.c:712 +#10 0x00005634a7a9392a in iothread_run (opaque=opaque@entry=0x5634a9998700) at ../iothread.c:67 +#11 0x00005634a7bc21d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#12 0x00007fcfaf084b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#13 0x00007fcfaf116a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1216368 b/results/classifier/accel-gemma3:12b/vmm/1216368 new file mode 100644 index 000000000..e91a4c105 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1216368 @@ -0,0 +1,18 @@ + +unsupported screen resolution crashes sdl-qemu + +if the (windows) guest sets a screen resolution that the SDL backend does not support, +qemu does an exit(1). +with this fix, the the resolution is still wrong (only part of the desktop is displayed), +but qemu keeps running and the guest can auto-revert the video mode: + +ui/sdl.c:do_sdl_resize() + SDL_Surface * tmp_screen; + tmp_screen = SDL_SetVideoMode(width, height, bpp, flags); + if (!tmp_screen) { +// fprintf(stderr, "Could not open SDL display (%dx%dx%d): %s\n", width, +// height, bpp, SDL_GetError()); +// exit(1); + } else { + real_screen = tmp_screen; + } \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1217339 b/results/classifier/accel-gemma3:12b/vmm/1217339 new file mode 100644 index 000000000..3b971f9d7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1217339 @@ -0,0 +1,8 @@ + +SIGQUIT to send ACPI-shutdown to Guest + +When qemu receives SIGQUIT, it should first try to run system_powerdown (giving the guest an ACPI signal to begin the shutdown process), before ending the whole qemu process. + +At this point there is no way to do a graceful shutdown if you do not have access to the monitor and you do not use any wrapper like libvirt. + +If, for some reason SIGQUIT would not be accepted as the signal, take any free to use signal, like SIGUSR1. There should be a way to get ACPI shutdown sent to the guest. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1218 b/results/classifier/accel-gemma3:12b/vmm/1218 new file mode 100644 index 000000000..460838780 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1218 @@ -0,0 +1,21 @@ + +bitmap lost when create snapshot using blockdev-snapshot-sync function +Description of problem: +bitmap will be lost when using the blockdev-snapshot-sync qmp command to create external snapshot. +if we create snapshot with the bitmap ,we have to start our incremental backup chain from a new full-backup. +Steps to reproduce: +1. start the qemu : +qemu-system-x86_64 -name guest=i-00001C,debug-threads=on -machine pc,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1 -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8 -device ich9-usb-ehci1,id=usb1,bus=pci.0,addr=0x9 -device piix4-usb-uhci,id=usb2,bus=pci.0,addr=0xb -device qemu-xhci,id=usb3,bus=pci.0,addr=0xc -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on -drive file=/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait + +2. {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-19-16-10-23"}} + +3. {"execute":"query-block"} and the result: + {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block173", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "**dirty-bitmaps**": [{"name": "bitmap-2022-09-19-16-10-23", "recording": true, "persistent": false, "busy": false, "granularity": 65536, "count": 0}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]} + +4. {"execute":"blockdev-snapshot-sync","arguments":{"device": "drive-virtio-disk0", "snapshot-file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "format": "qcow2"}} +5. {"execute":"query-block"} and the result: + {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "backing-filename-format": "qcow2", "virtual-size": 21474836480, "filename": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "full-backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block618", "backing_file_depth": 1, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "backing_file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]} + +we lost the bitmap bitmap-2022-09-19-16-10-23 +Additional information: +the bitmap attach the active bs, when changing the active bs ,the bitmap will be lost... diff --git a/results/classifier/accel-gemma3:12b/vmm/1220 b/results/classifier/accel-gemma3:12b/vmm/1220 new file mode 100644 index 000000000..0c7c9d8a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1220 @@ -0,0 +1,17 @@ + +when migrate,I unplugged the disk, why can't I force cancel the job task use qmp +Description of problem: +when migrate,I unplugged the disk,the block job will hung,but why can't I force cancel the job task +Steps to reproduce: +1.migrate a guset to another host with non-share disk (iscsi) + +2.unplug the disk + +3.then force cancel the block job task + + +but it not work,the cancle handle is not work + + + + diff --git a/results/classifier/accel-gemma3:12b/vmm/1223 b/results/classifier/accel-gemma3:12b/vmm/1223 new file mode 100644 index 000000000..ef611e74d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1223 @@ -0,0 +1,12 @@ + +When the disk is offline, why does the migration not time out and the virtual machine keeps hanging +Description of problem: +I want to the migrate end auto after the disk is offline +Steps to reproduce: +1.migrate to other host + +2.Manually construct disk offline when migrating + +3.the vm is hangs,and migrate wait for the disk recovery,i need to it timeout and report the failed migration +rather than hangs ,what should i do + diff --git a/results/classifier/accel-gemma3:12b/vmm/1223477 b/results/classifier/accel-gemma3:12b/vmm/1223477 new file mode 100644 index 000000000..48b1cf6cf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1223477 @@ -0,0 +1,31 @@ + +Unable to read USB filesystems with EFI Bios + +Preamble and version: +With respect to my fix for using USB devices as -hda mentioned in bug 1223467 +Using Qemu 1.6.0 with OVMF r11337-alpha (Qemu is built from Source, OVMF is pre built) + +Command: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 + +Fault: +The EFI Shell is able to detect the hda block device, report its capacity and usage; +but it sees no files or directories on the device. + +Similar commands: +I have also seen the same with +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 +and +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-x64 + +Investigations: +I tried very small (500MB) and very large (32 GB) USB devices with no difference. +I re-built several versions of Qemu in an identical build environment, and found that: +Qemu 1.2.2 and before, all the above commands work and the EFI boot loader is called. +Qemu 1.3.0-rc0 and after do not work and the USB device appears blank. +I'm reporting the bug here and not with OVMF because older versions of Qemu with the same OVMF bios work perfectly. + +In all cases using '-L pc-bios' works perfectly. +In all cases using an image of the USB device works. + +Thanks \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1226 b/results/classifier/accel-gemma3:12b/vmm/1226 new file mode 100644 index 000000000..94e0b3778 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1226 @@ -0,0 +1,26 @@ + +wheel-axis=false does not get applied at hardware init stage +Description of problem: +`-device virtio-tablet,id=touch0,wheel-axis=false` does not get applied at initalization stage, causing android to see it and treat the device as a pointer instead of a tablet. it seems to look for the prop at init stage, I have verified that this is an issue by fixing it with a quick hack below. ~~setting `-device virtio-tablet,id=touch0,wheel-axis=true` will still work fine and cause android to pick it up as a pointer again~~ + + +EDIT: It does not seem to work actually. if set when the default is set to false +Steps to reproduce: +1. Boot android based VM +2. test an app that forces touch only over pointer +Additional information: +``` +diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c +index a7a244a95d..3175f9c7d5 100644 +--- a/hw/input/virtio-input-hid.c ++++ b/hw/input/virtio-input-hid.c +@@ -477,7 +477,7 @@ static struct virtio_input_config virtio_tablet_config_v2[] = { + }; + + static Property virtio_tablet_properties[] = { +- DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true), ++ DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, false), + DEFINE_PROP_END_OF_LIST(), + }; + +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1236 b/results/classifier/accel-gemma3:12b/vmm/1236 new file mode 100644 index 000000000..020c5c1cf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1236 @@ -0,0 +1,47 @@ + +blockdev fixed vhdx trying to reserve space, also misleading error, Could not open file: Invalid argument +Description of problem: +The qemu-storage-daemon/other qemu commands will not start and will choke on requiring vhdx driver for the blockdev layer. +Opening a fixed-virtual-disk like fixed-vhdx should not reserve extra space, and should only overwrite as all blocks are already allocated. +Steps to reproduce: +1. Ensure that a partition size is such that after deciding a fixed-vhdx size, the remainder space after creation of fixed-vhdx is less than the fixed-vhdx. +2. Create a fixed-vhdx file +3. Try to start an nbd server with it +the qemu-storage-daemon will not start +Additional information: +I want to mention that I am testing qemu-storage-daemon under windows/hyperv + +So far, I want to report that it has **worked** for rawimg and qcow2-fixed. +See comment of 20220926 https://github.com/cloudbase/wnbd/issues/63#issuecomment-1257148849 + +The driver parameter ```vhdx``` to the blockdev argument seems to struggle with it. + +I wanted to check if the vhdx blockdev driver has the same VHDX-related-bugs as qemu-nbd +- #727 VHDX is corrupted on expansion. +- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts + +Even the the blockdev reference entries seem to have VHDX all over the place +- pg 318 https://readthedocs.org/projects/qemu/downloads/pdf/latest/ +- https://www.qemu.org/docs/master/system/qemu-block-drivers.html +- except conspicuously here !! https://www.qemu.org/docs/master/interop/qemu-storage-daemon-qmp-ref.html?highlight=blockdev#qapidoc-265 + + +``` +C:\Windows\System32>qemu-storage-daemon --version +qemu-storage-daemon version 7.1.0 (v7.1.0-11925-g4ec481870e-dirty) + +C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on +qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file: Could not open 'H:\gkpics01.vhdx': Invalid argument + +C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on +qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed: Parameter 'subformat' is unexpected + +C:\Windows\System32>dir H:\gkpics01.vhdx + Volume in drive H is CPERF0 + Volume Serial Number is F196-DB9E + Directory of H:\ +09/29/2022 08:55 PM 99,727,966,208 gkpics01.vhdx + 1 File(s) 99,727,966,208 bytes + 0 Dir(s) 4,312,399,872 bytes free +``` +## diff --git a/results/classifier/accel-gemma3:12b/vmm/1242765 b/results/classifier/accel-gemma3:12b/vmm/1242765 new file mode 100644 index 000000000..2431ee923 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1242765 @@ -0,0 +1,70 @@ + +USB passthrough to Windows 7 guest fails with error -110, hangs + +Description of problem: + +Using a Sandisk Cruzer Fit 16GB USB thumb drive. +Using virt-manager on Fedora 19 host, and Windows 7 32 bit guest. + +I set up a USB2 controller on Windows 7 guest in virt-manager. Windows sees the USB drive and can open the file manager and correctly show the files. I can copy a file from the thumb drive to the Fedora desktop, and then play the file on the desktop. However, any attempt to open a file directly on the thumb drive (example, play an MP3 using Windows Media Player) results in guest hang and host kernel messages: + + +Oct 19 21:15:35 localhost kernel: [187592.977839] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:40 localhost kernel: [187598.065274] usb 1-1.3: device descriptor read/all, error -110 +Oct 19 21:15:40 localhost kernel: [187598.138167] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:56 localhost kernel: [187613.218119] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.399275] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.573355] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:16 localhost kernel: [187633.587778] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.702244] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.876201] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:26 localhost kernel: [187643.890642] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.005071] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.106188] usb 1-1.3: USB disconnect, device number 13 +Oct 19 21:16:31 localhost kernel: [187649.178969] usb 1-1.3: new high-speed USB device number 14 using ehci-pci +Oct 19 21:16:47 localhost kernel: [187664.258945] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.440092] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.614194] usb 1-1.3: new high-speed USB device number 15 using ehci-pci +Oct 19 21:17:17 localhost kernel: [187694.694148] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187709.875297] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187710.049386] usb 1-1.3: new high-speed USB device number 16 using ehci-pci +Oct 19 21:17:37 localhost kernel: [187715.063803] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:17:41 localhost kernel: [187719.005453] usb 1-1.3: device descriptor read/8, error -71 + +After that -71 error, the thumb drive completely disappears from the host, as if it is powered down. + +I read that -110 is supposedly a power issue. I can play media files directly from the thumb drive on the host, so the power seems fine on the host. + + +How reproducible: +always + + +Steps to reproduce: +1. use virt-manager, create a Windows 7 32 bit guest +2. in virt-manager, set Controller USB to USB2 +3. on host, insert Sandisk Cruser Fit thumb drive FAT32 format, with an MP3 file on it +4. in virt-manager, add a USB passthrough device and assign it to thumb drive +5. boot Windows 7 guest +6. verify that Windows 7 can see the thumb drive +7. use Windows Media Player to play MP3 + +Actual results: +guest hangs, then host powers off thumb drive + +Expected results: +The MP3 file should play :) + + +Additional info: + +Fedora 19 + +Installed Packages +qemu-common.x86_64 2:1.4.2-11.fc19 @updates +qemu-guest-agent.x86_64 2:1.4.2-11.fc19 @updates +qemu-img.x86_64 2:1.4.2-11.fc19 @updates +qemu-kvm.x86_64 2:1.4.2-11.fc19 @updates +qemu-system-x86.x86_64 2:1.4.2-11.fc19 @updates +virt-manager.noarch 0.10.0-3.fc19 @updates +kernel.x86_64 3.11.1-200.fc19 @updates \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1243968 b/results/classifier/accel-gemma3:12b/vmm/1243968 new file mode 100644 index 000000000..9fb52d0ac --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1243968 @@ -0,0 +1,34 @@ + +VMware ESXi on QEmu Kernel Panic + +I attempted to install ESXi 5.5 (the free version) into a QEmu 1.6.1 VM. The guest OS does have the svm capabilities, but it appears VMware is trying to do some kind of hypercall that crashes the guest. + +There is more information here: https://communities.vmware.com/message/2297382 + +It seems to me that this stubbed feature should just be disabled if it is unusable. Or at the very least I should be able to disable it at run-time with a command-line argument. + +Is there some way to disable all the hypervisor features that makes it very obvious to a guest os that it is running inside a VM? It would be great if I could install a software and it would actually work (even if it's slow with those features disabled). + +FYI, my guest OS capabilities are: + +# cat /proc/cpuinfo +processor : 0 +vendor_id : AuthenticAMD +cpu family : 6 +model : 2 +model name : QEMU Virtual CPU version 1.5.3 +stepping : 3 +microcode : 0x1000065 +cpu MHz : 1999.999 +cache size : 512 KB +fpu : yes +fpu_exception : yes +cpuid level : 4 +wp : yes +flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 popcnt hypervisor lahf_lm svm abm sse4a +bogomips : 3999.99 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1247478 b/results/classifier/accel-gemma3:12b/vmm/1247478 new file mode 100644 index 000000000..9ef07281d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1247478 @@ -0,0 +1,25 @@ + +usb passthrough mass storage write data corruption + +the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb +in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and +except for the last packet for odd-sized files). The pattern is: +3 times bulk out 20480 +1 time bulk out 4096 + +and that repeats for files longer than 65536 bytes. + +the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each +20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and +57344-61440. +and so on. and because the 4096 sized bulk out is always error free, the next corrupt span is from +81920-86016. + +the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same +transfer. + +to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file. +(possibly check the bulk transfer sizes with usbmon). +note that attaching usb disks with hw/usb/dev-storage does work just fine. +cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are +always ok even with usb passthrough. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1252010 b/results/classifier/accel-gemma3:12b/vmm/1252010 new file mode 100644 index 000000000..6c9ec3d27 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1252010 @@ -0,0 +1,8 @@ + +can't assign enough RAM to the VM + +QEMU version: 1.6.90.0 from 2013 11 16 +Host OS: Windows XP SP3 x86 +Host machine: 3.2 GHz AMD Athlon 64 dual core processor, 4 GB DDR II (3.2 seen by the OS) memory +Guest OS: Grub4Dos boot manager menu +Problem: you can't assign more than 880 MB memory to the VM, although with 0.15.1.0 version you can assign up to 1179 MB. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1253563 b/results/classifier/accel-gemma3:12b/vmm/1253563 new file mode 100644 index 000000000..23c7ac45f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1253777 b/results/classifier/accel-gemma3:12b/vmm/1253777 new file mode 100644 index 000000000..ca61dbd44 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1253777 @@ -0,0 +1,20 @@ + +OpenBSD VM running on OpenBSD host has sleep calls taking twice as long as they should + +Running a script like + +while [ 1 ] +do + date + sleep 1 +done + +on the VM will result in the (correct) date being displayed, but it is displayed only every two (!) seconds. We have also noticed that if we connect to the VM's console using VNC, and move the mouse pointer constantly in the VNC window, the script runs normally with updates every second! Note that the script doesn't have to be running on the VM's console - it's also possible to (say) ssh to the VM from a separate machine and run the script and it will display the '2 second' issue, but as soon as you move the mouse pointer constantly in the VNC console window the script starts behaving normally with updates every second. + +I have only seen this bug when running an OpenBSD VM on an OpenBSD host. Running an OpenBSD VM on a Linux host does not exhibit the problem for me. I also belive (am told) that a Linux VM running on an OpenBSD host does not exhibit the problem. + +I have been using the OpenBSD 5.4 64 bit distro which comes with qemu 1.5.1 in a package, however I tried compiling qemu 1.6.1 and that has the same bug. In fact older OpenBSD distros have the same issue - going back to OpenBSD distros from two years ago still have the problem. This is not a 'new' bug recently introduced. + +Initially I wondered if it could be traced to an incorrectly set command line option, but I've since gone through many of the options in the man page simply trying different values (eg. different CPU types ( -cpu) , different emulated PC (-M)) but so far the problem remains. + +I'm quite happy to run tests in order to track this bug down better. We use qemu running on OpenBSD extensively and find it very useful! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1256432 b/results/classifier/accel-gemma3:12b/vmm/1256432 new file mode 100644 index 000000000..ffb1c9794 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1256432 @@ -0,0 +1,4 @@ + +qemu mingw 32bit windows crash + +is it a known bug that in windows that even if you do ./configure --disable-coroutine-pool it still builds the coroutine stuff so when you try and run the build after its compiled it crashses? you have to actually edit config-host.mak and change the c flags around. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1256548 b/results/classifier/accel-gemma3:12b/vmm/1256548 new file mode 100644 index 000000000..3352880e2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1256548 @@ -0,0 +1,12 @@ + +qemu windows guest issues + +Ive noticed the following in the latest qemu build on mingw 64bit for windows + +older guests like windows 9* no longer boot they mostly just bsod its been this way for ages same with 32bit builds +xp 64bit and other 64bit windows guests no longer work and havent for ages same with 32bit builds +xp 32bit guest doesent work under 64bit builds but they work on 32bit builds + +are the issues with the coroutine stuff on windows builds being worked on? id gladly test patches + +just a few observations is all :) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1261320 b/results/classifier/accel-gemma3:12b/vmm/1261320 new file mode 100644 index 000000000..2e7993535 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1261320 @@ -0,0 +1,16 @@ + +Virtual Disk with over 16TB + +Hi, + +is there a option to create a disk for a vm with a size over 16TB. + +the problem that after the diskfile reach 16TB, the disk get a state of read-only at this limit. +I know, that 16TB file size is max, is there a option to create the disk in mutliple files? +we want to use 22 TB. in the VM + +To attach a partition directly to the vm, is not what we want to do. + +best regards + +Chris \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1261450 b/results/classifier/accel-gemma3:12b/vmm/1261450 new file mode 100644 index 000000000..eeecd1daa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1261450 @@ -0,0 +1,80 @@ + +libvirtd reload and hooks problem routed-net + +if we do a reload of libvirt, some iptables rules, which are created through /etc/libvirt/hooks/qemu are not working anymore. +Every time a other (one or two,thee) vm is affected. + + +our qemu file: + +#!/bin/bash + + +do_net() { + local status=$2 + local ip=$3 + local in=$4 + local out=$5 + + if [[ ! $status || ! $ip || ! $in || ! $out ]]; then + echo "Not all parameters were passed!" + exit 1 + fi + + if [ "$status" = "stopped" -o "$status" = "reconnect" ]; then + ip route del $ip via 191.255.255.1 dev $out + ip neigh del proxy $ip dev $in + iptables -D FORWARD -i $in -o $out -s 0.0.0.0/0 -d $ip/32 -j ACCEPT + iptables -D FORWARD -i $out -o $in -s $ip/32 -d 0.0.0.0/0 -j ACCEPT + fi + + if [ "$status" = "start" -o "$status" = "reconnect" ]; then + ip route add $ip via 191.255.255.1 dev $out + ip neigh add proxy $ip dev $in + iptables -I FORWARD 4 -i $in -o $out -s 0.0.0.0/0 -d $ip/32 -j ACCEPT + iptables -I FORWARD 4 -i $out -o $in -s $ip/32 -d 0.0.0.0/0 -j ACCEPT + fi +} + +CONF=//etc/libvirt/hooks/vms/* +for file in $CONF +do + guest_ipaddr="" + guest_name="" + type="" + destination="0.0.0.0/0" + + while read line; do + eval $line + done < $file + guest_ipaddrnet=$guest_ipaddr"/32" + for dest in ${destination} + do + if [ "${1}" = "${guest_name}" ]; then + echo "SRC-IP="$guest_ipaddr " " $guest_ipaddrnet " VM="$guest_name " Dest="$dest + if [ "${2}" = "stopped" ]; then + ip route del $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh del proxy $guest_ipaddr dev bond0 + iptables -D FORWARD -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -D FORWARD -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + fi + if [ "${2}" = "start" ]; then + ip route add $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh add proxy $guest_ipaddr dev bond0 + iptables -I FORWARD 4 -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -I FORWARD 4 -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + fi + if [ "${2}" = "reconnect" ]; then + ip route del $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh del proxy $guest_ipaddr dev bond0 + iptables -D FORWARD -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -D FORWARD -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + sleep 1 + ip route add $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh add proxy $guest_ipaddr dev bond0 + iptables -I FORWARD 4 -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -I FORWARD 4 -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + fi + fi + done +done \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1262 b/results/classifier/accel-gemma3:12b/vmm/1262 new file mode 100644 index 000000000..43cc60c4c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1262 @@ -0,0 +1,2 @@ + +avocado test framework fails to report when QEMU exits unexpectedly diff --git a/results/classifier/accel-gemma3:12b/vmm/1264 b/results/classifier/accel-gemma3:12b/vmm/1264 new file mode 100644 index 000000000..b21c8e627 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1264 @@ -0,0 +1,2 @@ + +socket chardev loses data when remote end closes the connection diff --git a/results/classifier/accel-gemma3:12b/vmm/1265 b/results/classifier/accel-gemma3:12b/vmm/1265 new file mode 100644 index 000000000..895a3afe7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1265 @@ -0,0 +1,2 @@ + +avocado should log all the guest console output until QEMU exits, not disconnect early diff --git a/results/classifier/accel-gemma3:12b/vmm/1269628 b/results/classifier/accel-gemma3:12b/vmm/1269628 new file mode 100644 index 000000000..e7a6eb85c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1269628 @@ -0,0 +1,6 @@ + +Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation + +In order to allow windows guests (and soon, linux guests) which are TCG OPAL 2 aware to perform disk encryption in a native fashion with hardware acceleration, please add TCG OPAL 2 emulation to the VIRTIO driver. + +Encryption should occur at the host level using any cryptographic facilities available to the host, for example AES-NI, Cryptography Hardware, underlying block device cryptography support where available or any other cryptography facility that may be developed and implemented in the future. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1279 b/results/classifier/accel-gemma3:12b/vmm/1279 new file mode 100644 index 000000000..4cde59a42 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1279 @@ -0,0 +1,9 @@ + +please assist resolving windows networking issue +Description of problem: +After Installation of Windows, for Intel E1000 , Realtek and VirtIO, Windows shows "Error Code 56: Windows is Still Setting Up the Class Configuration For This Device" in device manager and Network won't work +Steps to reproduce: +Install Windows 10 VM on Proxmox 7.2 with virtual hardware Version 6.1 +You get the error code above. When using virtio nic , during installation of the kvm-qemu-virtio driver/agent package, the installer get's stuck and finally fails. + +If you downgrade to virtual hardware 5.1 , the problem goes away. diff --git a/results/classifier/accel-gemma3:12b/vmm/128 b/results/classifier/accel-gemma3:12b/vmm/128 new file mode 100644 index 000000000..71de6e7a4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/128 @@ -0,0 +1,2 @@ + +man page is missing suboptions for "-display" diff --git a/results/classifier/accel-gemma3:12b/vmm/1284090 b/results/classifier/accel-gemma3:12b/vmm/1284090 new file mode 100644 index 000000000..ad4475957 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1284090 @@ -0,0 +1,9 @@ + +RFE: QMP: report error reason in BLOCK_IO_ERROR message + +when a disk drive is configured with the error policy enospc for write errors, the monitoring client needs a way to distinguish +betwwen generic I/O error and the I/O error for space exausted. + +The JSON QMP protocol lacks this information: the BLOCK_IO_ERROR message does not provide a reason or code for the error verified, so the monitoring client cannot distinguish the source of the errors. + +verified against git 105a060188dc6fdd4551571a966514d1a5f6815a \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1285 b/results/classifier/accel-gemma3:12b/vmm/1285 new file mode 100644 index 000000000..92783a115 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1285 @@ -0,0 +1,21 @@ + +Can't use spice-app on macOS because GIO can't find handler for spice+unix scheme +Description of problem: +``` +qemu-system-aarch64: info: Launching display with URI: spice+unix:///tmp/.U96NU1/spice.sock +qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'. +qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'. +qemu-system-aarch64: Failed to launch spice+unix:///tmp/.U96NU1/spice.sock URI: Operation not supported +qemu-system-aarch64: You need a capable Spice client, such as virt-viewer 8.0 +``` + +``` +$ virt-viewer --version +virt-viewer version 11.0 +``` +Steps to reproduce: +1. Have virt-viewer in $PATH +2. Run command above +3. Observe error above +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1291 b/results/classifier/accel-gemma3:12b/vmm/1291 new file mode 100644 index 000000000..8072872f8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1291 @@ -0,0 +1,2 @@ + +--enable-jemalloc configure option is not covered in CI diff --git a/results/classifier/accel-gemma3:12b/vmm/1299 b/results/classifier/accel-gemma3:12b/vmm/1299 new file mode 100644 index 000000000..565146549 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1299 @@ -0,0 +1,25 @@ + +User networking with an SMB Share while not running as root +Description of problem: +When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED. + +This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now. +Steps to reproduce: +1. Start a VM with a SMB share attached to it +2. Create a test file to upload `touch test-file.txt` +3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt' +Additional information: +QEMU has been using Samba for it's SMB shares for quite some time now. +But in the 4.17.x release a bug has appeared in the MacOS Build of Samba. + +I've filed a bug with Samba, and suggested a fix for it. +https://bugzilla.samba.org/show_bug.cgi?id=15215 + +The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly. +But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case. + +Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner. + +As a side note, on Linux this bug does not appear to exist as of yet. +The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install). +But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation. diff --git a/results/classifier/accel-gemma3:12b/vmm/1299190 b/results/classifier/accel-gemma3:12b/vmm/1299190 new file mode 100644 index 000000000..676b53472 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1299190 @@ -0,0 +1,8 @@ + +Access to /proc/self/exe in linux-user mode + +This is based on a recent bug in GCC Bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 + +It looks like libbacktrace (GCC runtime library used for obtaining stack traces) uses /proc/self/exe for error reporting. Currently this is mapped to qemu-arm which effectively disables libbacktrace on linux-user. + +It seems that QEMU already supports /proc/self/{maps,stat,auxv} so addition of /proc/self/exe may be trivial. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1299858 b/results/classifier/accel-gemma3:12b/vmm/1299858 new file mode 100644 index 000000000..f6b95d8f5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1299858 @@ -0,0 +1,10 @@ + +qemu all apps crash on OS X 10.6.8 + +qemu-2.0.0-rc0 (and 1.7.1) crashes with SIGABORT in all apps when configured with --with-coroutine=sigaltstack (which is what configure selects by default) but all run fine if configured with --with-coroutine=gthread. + +Crash is at line 253 (last line of Coroutine *qemu_coroutine_new(void)) in coroutine-sigaltstack.c in 2.0.0-rc0 tarball. + +Platform is OS X 10.6.8 (Darwin Kernel Version 10.8.0), compiler gcc 4.2.1 + +Sorry for the sparse report but I'm short on time today. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1300 b/results/classifier/accel-gemma3:12b/vmm/1300 new file mode 100644 index 000000000..69ba14387 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1300 @@ -0,0 +1,12 @@ + +Build failure when configuring CONFIG_VHOST_USER_FS/CONFIG_VIRTIO +Description of problem: +Attempting to configure CONFIG_VHOST_USER_FS or CONFIG_VIRTIO results in a build failure. Complete build log (with configure output) is attached. +Steps to reproduce: +1. Add `CONFIG_VIRTIO` and `CONFIG_VHOST_USER_FS` (`y` *or* `n`) to `configs/devices/x86_64-softmmu/gentoo.mak` (done via the [ebuild](https://github.com/gentoo/gentoo/blob/master/app-emulation/qemu/qemu-7.1.0.ebuild)) +2. Configure with `--with-devices-x86_64=gentoo` +3. Attempt building +Additional information: +[build.log](/uploads/72fc1284f5245d9384e521d3b1c65953/build.log) + +Reported downstream [here](https://bugs.gentoo.org/873190). diff --git a/results/classifier/accel-gemma3:12b/vmm/1301 b/results/classifier/accel-gemma3:12b/vmm/1301 new file mode 100644 index 000000000..134f904f9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1301 @@ -0,0 +1,18 @@ + +qemu-system-ppc in Homebrew on macOS has mouse warps and ghost clicks +Description of problem: +The QEMU version in Homebrew (Intel macOS host, PowerPC Mac OS 9 guest) has random warping of the mouse cursor as well as ghost clicks which begin as soon as the operating system finishes loading. Video demonstration: https://youtu.be/DjXO0hwHArk + +Notably, the exact same version of the QEMU source code with the same build arguments built *outside* of the Homebrew environment does not have this issue. I copied the following arguments from the QEMU Homebrew formula, and tried building QEMU on the command line: + + ../configure --prefix=/Users/josh/Desktop/qemu-homebrew-build --cc=clang --host-cc=clang --disable-bsd-user --disable-guest-agent --enable-capstone --enable-curses --enable-libssh --enable-slirp --enable-vde --enable-virtfs --enable-zstd --extra-cflags=-DNCURSES_WIDECHAR=1 --disable-sdl --smbd=/usr/local/sbin/samba-dot-org-smbd --disable-gtk --enable-cocoa --target-list=ppc-softmmu + +This creates a `qemu-system-ppc` binary which is 15MB in size and works perfectly. By contrast, the exact same build commands within the Homebrew build process create a binary which is 10MB in size (!!!) and has this mouse warping and ghost clicks issue. This occurs whether QEMU was installed with `brew install qemu` or `brew install --build-from-source qemu`. Providing the `--HEAD` argument also makes no difference. The list of linked libraries (via `otool -L qemu-system-ppc`) is the same between the two versions. + +The only way I can reproduce this issue outside of Homebrew is to dump the Homebrew environmental variables (with `env`) to a file and then set up those same environmental variables with the `source` command, after which the resulting `qemu-system-ppc` binary is now 10MB in size like the Homebrew version, and has the mouse issue like the Homebrew version. I'll attach the file with the Homebrew environmental variables. It seems that the issue must lie somewhere in there, but I'm really pushing the limits of my abilities, so I could definitely use some ideas and/or insights. +Steps to reproduce: +1. Install QEMU via `brew install qemu` +2. Start QEMU with an image of Mac OS 9 +3. After the boot process completes, the issue manifests +Additional information: +[Homebrew_ENV_Variables.txt](/uploads/2393aed8f29fa9c32bcaca44281bd2a5/Homebrew_ENV_Variables.txt) diff --git a/results/classifier/accel-gemma3:12b/vmm/1305 b/results/classifier/accel-gemma3:12b/vmm/1305 new file mode 100644 index 000000000..a25b3daf5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1305 @@ -0,0 +1,15 @@ + +qemu will detach usbredir if backend chardev socket disconnect +Description of problem: +When using the usbredir device in the VM, initiate a hot migration to the VM. +After the migration is completed, the drive letter of the usb in the VM has changed. +Actually the device has been unplugged and re-plugged in the VM. +I think we should keep the plugged state of the device after the migration? +Steps to reproduce: +1. Start a usbredirserver `usbredirserver -p 7000 -v 4 5-2`; +2. Start a VM with a usbredir device attached to it; +3. Mount the usb device in the VM; +4. Migrate the VM, after the migration done, wait a minute，the drive letter of the usb in the VM has changed. +Additional information: +I've found this bug https://bugzilla.redhat.com/show_bug.cgi?id=1254971, this is just to allow the chardev to be reconnected in time when it is disconnected. +Can we make chardev reconnect without unpluging the usbredir device? diff --git a/results/classifier/accel-gemma3:12b/vmm/1307 b/results/classifier/accel-gemma3:12b/vmm/1307 new file mode 100644 index 000000000..6094097ff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1307225 b/results/classifier/accel-gemma3:12b/vmm/1307225 new file mode 100644 index 000000000..3324d863a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1307225 @@ -0,0 +1,23 @@ + +Running a virtual machine on a Haswell system produces machine check events + +I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable version on Gentoo). I got a lot of machine check events ("mce: [Hardware Error]: Machine check events logged") in dmesg that always looked like (using mcelog): + +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1390267908 Tue Jan 21 02:31:48 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 6 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I found this discussion on the vmware community: https://communities.vmware.com/thread/452344 + +It seems that this is (at least partly) caused by the Qemu machine. I switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With this version, the errors almost disappeared, but from time to time, I still get machine check events. Anyways, they so not seem to affect neither the vm, nor the host. + +I created the virtual machine on an older Core 2 Duo machine and ran it for several weeks without a single error message, so I think this is actually some problem with the Haswell architecture. The errors didn't show up until I copied the virtual machine to my new machine. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1308 b/results/classifier/accel-gemma3:12b/vmm/1308 new file mode 100644 index 000000000..7ac8c8578 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1308 @@ -0,0 +1,2 @@ + +Qemu headless build process is stopped, complaining about a missing pixman.h diff --git a/results/classifier/accel-gemma3:12b/vmm/1309 b/results/classifier/accel-gemma3:12b/vmm/1309 new file mode 100644 index 000000000..c7f20691e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1309 @@ -0,0 +1,2 @@ + +Heap-overflow in virtio_net_queue_enable diff --git a/results/classifier/accel-gemma3:12b/vmm/131 b/results/classifier/accel-gemma3:12b/vmm/131 new file mode 100644 index 000000000..786c252fc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/131 @@ -0,0 +1,2 @@ + +QEMU's default msrs handling causes Windows 10 64 bit to crash diff --git a/results/classifier/accel-gemma3:12b/vmm/1324724 b/results/classifier/accel-gemma3:12b/vmm/1324724 new file mode 100644 index 000000000..d4fa1fa23 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1324724 @@ -0,0 +1,21 @@ + +make install fails if running strip + +I do: + ./configure --target-list=arm-softmmu + make + sudo make install + +and see: +install -d -m 0755 "/usr/local/bin" +libtool --quiet --mode=install install -c -m 0755 qemu-ga qemu-nbd qemu-img qemu-io fsdev/virtfs-proxy-helper "/usr/local/bin" +strip "/usr/local/bin/qemu-ga" "/usr/local/bin/qemu-nbd" "/usr/local/bin/qemu-img" "/usr/local/bin/qemu-io" "/usr/local/bin/fsdev/virtfs-proxy-helper" +strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file +Makefile:379: recipe for target 'install' failed +make: *** [install] Error 1 + + +Host is Odroid-XU running Debian Jessie. +Source is at d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-peter' + +libtool version 2.4.2-1.7 armhf \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1329 b/results/classifier/accel-gemma3:12b/vmm/1329 new file mode 100644 index 000000000..d835525c5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1329 @@ -0,0 +1,13 @@ + +Screen doesn't update until mouse pointer moves over it +Description of problem: +When changing the color scheme in CDE, the screen should change +color everywhere at once, but doesn't do so. It only updates +in the area where the mouse moves. And there it does so over +the whole width of the screen . +Steps to reproduce: +1. Change color scheme in CDE +2. Move around mouse pointer +Additional information: +Screen capture of the problem +https://youtu.be/qZJzACIxSuk diff --git a/results/classifier/accel-gemma3:12b/vmm/133 b/results/classifier/accel-gemma3:12b/vmm/133 new file mode 100644 index 000000000..e2b3e6e90 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/133 @@ -0,0 +1,2 @@ + +Chardev websocket might not support pasting more than a few chars diff --git a/results/classifier/accel-gemma3:12b/vmm/1333216 b/results/classifier/accel-gemma3:12b/vmm/1333216 new file mode 100644 index 000000000..502061970 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1333216 @@ -0,0 +1,37 @@ + +Xen 4.4 with qemu 1.6.2 VGA passthru NVIDIA + +Hi! + +Please, give me an advice. + +I try use VGA passthough NVidia k40 on SuperMicro Server, but server is having error. +My Xen is using qemu (a9e8aeb3755bccb7b51174adcf4a3fc427e0d147)2.0.0 + +My VirtualMachine is have config: +device_model_version = "qemu-xen" +device_model_override = "/opt/sources/qemu-a9e8aeb/x86_64-softmmu/qemu-system-x86_64" + +When I start VM: +dmesg +[ 0.906181] pci 0000:00:05.0: BAR 1: can't assign mem pref (size 0x100000000) +[ 0.906187] pci 0000:00:05.0: BAR 1: trying firmware assignment [mem 0x100000000-0x1ffffffff 64bit pref] +[ 0.906193] pci 0000:00:05.0: BAR 1: assigned [mem 0x100000000-0x1ffffffff 64bit pref] +and lspci -s 00:05.0 -vvv + Region 0: Memory at 85000000 (32-bit, non-prefetchable) [size=16M] + Region 1: Memory at 100000000 (64-bit, prefetchable) [size=4G] + Region 3: Memory at 82000000 (64-bit, prefetchable) [size=32M] + +Why? + +This is message in DOM0: +lspci -s 03:00.0 -vvv +.... +Region 0: Memory at de000000 (32-bit, non-prefetchable) [size=16M] +Region 1: Memory at 5800000000 (64-bit, prefetchable) [size=16G] +Region 3: Memory at 5c00000000 (64-bit, prefetchable) [size=32M] + + +Why Qemu don`t mapping BAR1? +Thanks! +Regards! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1333688 b/results/classifier/accel-gemma3:12b/vmm/1333688 new file mode 100644 index 000000000..064495cf1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1333688 @@ -0,0 +1,58 @@ + +vhost-user: VHOST_USER_SET_MEM_TABLE doesn't contain all regions + + + +vhost-user implementation doesn't provide information about all memory regions, +and in some cases client is not able to map buffer memory as he is missing +memory region information for specific address. + +Same thing is implemented properly for vhost-net. Below gdb outputs are +showing memory regions information provided to the vhost-net and vhost-user. + + + +==== memory regions information provided to vhost-net ==== + +(gdb) p/x hdev->mem->regions[0] +$21 = { + guest_phys_addr = 0x100000000, + memory_size = 0xc0000000, + userspace_addr = 0x2aab6ac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[1] +$22 = { + guest_phys_addr = 0xfffc0000, + memory_size = 0x40000, + userspace_addr = 0x7ffff4a00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[2] +$23 = { + guest_phys_addr = 0x0, + memory_size = 0xa0000, + userspace_addr = 0x2aaaaac00000, + flags_padding = 0x0 +} +(gdb) p/x hdev->mem->regions[3] +$24 = { + guest_phys_addr = 0xc0000, + memory_size = 0xbff40000, + userspace_addr = 0x2aaaaacc0000, + flags_padding = 0x0 +} +(gdb) + + +==== memory regions information provided to vhost-user ==== + +(gdb) p/x msg.memory.nregions +$28 = 0x1 +(gdb) p/x msg.memory.regions[0] +$29 = { + guest_phys_addr = 0x0, + memory_size = 0x180000000, + userspace_addr = 0x2aaaaac00000 +} +(gdb) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1337 b/results/classifier/accel-gemma3:12b/vmm/1337 new file mode 100644 index 000000000..503a6b62d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1337 @@ -0,0 +1,17 @@ + +Incorrect warnings when using vhost without numa +Description of problem: +Part A: Misleading error message. Running the above command for any architecture fails to initialize vhost, and prints the following, incorrect advice +``` +qemu-system-mips: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on +qemu-system-mips: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-mips: Error starting vhost: 22 +``` + +Since the command line already contains `-object memory-backend-file,id=mem1,mem-path=/tmp/mem,size=256M,share=on` this error message should not be printed. For x86_64, this can be resolved by adding `-numa node,memdev=mem0` to the command line. As such, I think this error message should instead guide a user to adding that argument. + +Part B: No documented configuration to run vhost-user for machines that don't support numa. +The mips malta machine does not support the `-numa` flag. It is unclear if this means that `vhost` cannot be used with this platform or if a non-numa configuration with a memory-backend-file can be used. +Steps to reproduce: +1. Run `vhost-user-vsock --socket=/tmp/vhost4.socket --uds-path=/tmp/foo` from https://github.com/rust-vmm/vhost-device. +1. Run the above QEMU command diff --git a/results/classifier/accel-gemma3:12b/vmm/1338591 b/results/classifier/accel-gemma3:12b/vmm/1338591 new file mode 100644 index 000000000..57ad5e4fd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1338591 @@ -0,0 +1,20 @@ + +Cursor jumps on shape change with vmware vga + +I launch QEMU with the following command line: + +qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm + +The guest OS is Windows XP. To reproduce the problem, do this: + +0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA +1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. +2. Open a text editor, e.g. built-in notepad +3. Move the cursor inside text entry widget +4. See the cursor jumping away. You basically can't enter the cursor there. + +This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. + +This doesn't happen with other VGAs, i.e. cirrus and std. + +I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1338957 b/results/classifier/accel-gemma3:12b/vmm/1338957 new file mode 100644 index 000000000..e7eff4ef2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1338957 @@ -0,0 +1,12 @@ + +RFE: add an event to report block devices watermark + +Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query-blockstats output. + +Rationale for the RFE +Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images. +In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded. + +In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor +using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios +with hunderds of VM are becoming not unusual. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1343827 b/results/classifier/accel-gemma3:12b/vmm/1343827 new file mode 100644 index 000000000..2d4a410a5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1343827 @@ -0,0 +1,45 @@ + +block.c: multiwrite_merge() truncates overlapping requests + +If the list of requests passed to multiwrite_merge() contains two requests where the first is for a range of sectors that is a strict subset of the second's, the second request is truncated to end where the first starts, so the second half of the second request is lost. + +This is easy to reproduce by running fio against a virtio-blk device running on qemu 2.1.0-rc1 with the below fio script. At least with fio 2.0.13, the randwrite pass will issue overlapping bios to the block driver, which the kernel is happy to pass along to qemu: + +[global] +randrepeat=0 +ioengine=libaio +iodepth=64 +direct=1 +size=1M +numjobs=1 +verify_fatal=1 +verify_dump=1 + +filename=$dev + +[seqwrite] +blocksize_range=4k-1M +rw=write +verify=crc32c-intel + +[randwrite] +stonewall +blocksize_range=4k-1M +rw=randwrite +verify=meta + +Here is a naive fix for the problem that simply avoids merging problematic requests. I guess a better solution would be to redo qemu_iovec_concat() to do the right thing. + +diff -ur old/qemu-2.1.0-rc2/block.c qemu-2.1.0-rc2/block.c +--- old/qemu-2.1.0-rc2/block.c 2014-07-15 14:49:14.000000000 -0700 ++++ qemu-2.1.0-rc2/block.c 2014-07-17 23:03:14.224169741 -0700 +@@ -4460,7 +4460,9 @@ + int64_t oldreq_last = reqs[outidx].sector + reqs[outidx].nb_sectors; + + // Handle exactly sequential writes and overlapping writes. +- if (reqs[i].sector <= oldreq_last) { ++ // If this request ends before the previous one, don't merge. ++ if (reqs[i].sector <= oldreq_last && ++ reqs[i].sector + reqs[i].nb_sectors >= oldreq_last) { + merge = 1; + } \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1355738 b/results/classifier/accel-gemma3:12b/vmm/1355738 new file mode 100644 index 000000000..80f84150a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1355738 @@ -0,0 +1,19 @@ + +qemu-img: Killed by SIGTRAP on check of the fuzzed image + +'qemu-img check -r all' was killed by SIGTRAP. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.qed in the same directory + 3. Execute + +qemu-img check -f qcow2 -r all copy.img + +Result: qemu-img was killed by SIGTRAP with the reason: + +(process:2210): GLib-ERROR **: gmem.c:140: failed to allocate 18446744069633940288 bytes + +The qemu-img execution log can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1357445 b/results/classifier/accel-gemma3:12b/vmm/1357445 new file mode 100644 index 000000000..59d96a812 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1357445 @@ -0,0 +1,16 @@ + +qemu-img: 'amend -o compat=0.10' command failed with segfault on the fuzzed image + +qemu-img amend -o compat=0.10' failed with a segmentation fault on the fuzzed image. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.qed in the same directory + 3. Execute + qemu-img amend -o compat=0.10 -f qcow2 copy.img + +Result: qemu-img was killed by SIGSEGV. + +Traces can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1358722 b/results/classifier/accel-gemma3:12b/vmm/1358722 new file mode 100644 index 000000000..32727f567 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1358722 @@ -0,0 +1,16 @@ + +latest acpi commits causes memory allocation fault in macosx + +qemu release 2.1.0 + +Hi, +I've found a regression on MacOSX guest (10.9.4) after merging the following commits + +18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof migration-compatibility of ACPI tables +868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration limits + +The migration limits make x86 chameleon bootloader generate a memory allocation error with 0xdeadbeef address at line 899 in source file: + +http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c + +I've not tried to recompile chameleon yet. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1362 b/results/classifier/accel-gemma3:12b/vmm/1362 new file mode 100644 index 000000000..cf210e9b6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1362 @@ -0,0 +1,76 @@ + +BLKZEROOUT ioct/write requests getting split a weird boundary (and for no apparent reason?) +Description of problem: +i was investigating into some performance weirdness with passthrough/directly-mapped SAS vs. SATA disk, which seems to relate to detect_zeroes feature (see https://forum.proxmox.com/threads/disk-passthrough-performance-weirdness.118943/#post-516599 ). + +apparently, writing zeroes to passtrough/direct-mapped sas disk ( ST4000NM0034 ) in virtual machine is MUCH slower then sata disk ( HGST HDN728080AL ). + +with detect_zeroes=on (default in proxmox) , qemu converts writes of zeroes into BLKZEROOUT ioctl issued to the target disk, and my sas disk is much much slower with this (<80MB/s in comparison to the sata disk with 200MB/s). + +i found that the sas disk needs 0.01s on average for this ioctl to finish, whereas sata disk needs 0.004s. + +writing zeroes to the device directly is at about 200MB/s for both of them, so having detect_zeroes=on a default does not seem to be an advantage on all circumstances. + +anyway, i have made a weird observation during analysis: + +inside the virtual machine, i'm writing to the virtual disk like this: + +``` +dd if=/dev/zero of=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 bs=1024k count=1024 oflag=direct + +(scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 mapped to scsi-35000c500836b1c73 / SAS on the host, scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 mapped to ata-HGST_HDN728080ALE604_VJGDNX5X ) + +``` + +on the HOST i'm attaching to the kvm process with strace , every time i issue the above dd inside VM, kvm/qemu process issues BLKZEROOUT to the device in a different way, i.e. either + +- within a single ioctl at originating 1048576 byte size (=1024k) +or +- split into 2 ioctl with 1040384+8192(=1048576) +or +- split into 2 ioctl with 1044480+4096(=1048576) + + +why does kvm/qemu sometimes split the write request and sometimes not ? and why at such a weird boundary just below 1Mb? + + +i don't know if this is a bug, but at least it looks weird to me, that's why i'm reporting + +``` + +root@pve:~/util-linux/sys-utils# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 65413] ioctl(19, BLKZEROOUT, [0, 1048576] <unfinished ...> +[pid 65412] ioctl(19, BLKZEROOUT, [1048576, 1048576] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [2097152, 1048576] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1048576] <unfinished ...> +[pid 65412] ioctl(19, BLKZEROOUT, [4194304, 1048576]) = 0 <0.011287> +[pid 65366] ioctl(19, BLKZEROOUT, [5242880, 1048576]) = 0 <0.012025> +[pid 65413] ioctl(19, BLKZEROOUT, [6291456, 1048576]) = 0 <0.011377> +[pid 65412] ioctl(19, BLKZEROOUT, [7340032, 1048576] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [8388608, 1048576] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [9437184, 1048576]) = 0 <0.011705> + +# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 65878] ioctl(19, BLKZEROOUT, [0, 1040384] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [1040384, 8192] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [1048576, 1040384] <unfinished ...> +[pid 65878] ioctl(19, BLKZEROOUT, [2088960, 8192] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [2097152, 1040384] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [3137536, 8192] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1040384] <unfinished ...> +[pid 65878] ioctl(19, BLKZEROOUT, [4186112, 8192] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [4194304, 1040384] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [5234688, 8192] <unfinished ...> + +root@pve:~/util-linux/sys-utils# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 66591] ioctl(19, BLKZEROOUT, [0, 1044480] <unfinished ...> +[pid 66592] ioctl(19, BLKZEROOUT, [1044480, 4096] <unfinished ...> +[pid 66593] ioctl(19, BLKZEROOUT, [1048576, 1044480] <unfinished ...> +[pid 66584] ioctl(19, BLKZEROOUT, [2093056, 4096] <unfinished ...> +[pid 66585] ioctl(19, BLKZEROOUT, [2097152, 1044480] <unfinished ...> +[pid 66565] ioctl(19, BLKZEROOUT, [3141632, 4096] <unfinished ...> +[pid 66591] ioctl(19, BLKZEROOUT, [3145728, 1044480] <unfinished ...> +[pid 66592] ioctl(19, BLKZEROOUT, [4190208, 4096] <unfinished ...> +[pid 66584] ioctl(19, BLKZEROOUT, [4194304, 1044480] <unfinished ...> +[pid 66593] ioctl(19, BLKZEROOUT, [5238784, 4096] <unfinished ... +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1364 b/results/classifier/accel-gemma3:12b/vmm/1364 new file mode 100644 index 000000000..994b37ba9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1364 @@ -0,0 +1,16 @@ + +Support vmnet networking without elevated permissions +Additional information: +Here is a command, that doesn't work when running as normal user: +```bash +$ qemu-system-aarch64 \ + -device virtio-net-pci,netdev=net0 \ + -netdev vmnet-bridged,id=net0,ifname=en0 \ + -machine virt +``` +It fails with: +``` +qemu-system-aarch64: -netdev vmnet-bridged,id=net0,ifname=en0: cannot create vmnet interface: general failure (possibly not enough privileges) +``` + +When running the same command using elevated permissions (i.e. via `sudo`), it works without any issue. diff --git a/results/classifier/accel-gemma3:12b/vmm/1366 b/results/classifier/accel-gemma3:12b/vmm/1366 new file mode 100644 index 000000000..322ee709d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1366 @@ -0,0 +1,85 @@ + +Data inconsistency on LVM logical volume mounted as partition on ubuntu guest, when the written file's size is equal or greater than 27G. +Description of problem: +On the guest, writing a 27Gib file or larger result in inconsistent file checksum upon subsequent read. +Steps to reproduce: +**On the host** + +0. Create a LVM logical volume on a Linux RAID 1 (with 1 disk only) + +``` + --- Logical volume --- + LV Path /dev/davidahw2-vg4/lv0 + LV Name lv0 + VG Name davidahw2-vg4 + LV UUID 5FbDcl-eSDe-7cXL-22tj-Lg6O-79AL-4Gq7gx + LV Write Access read/write + LV Creation host, time davida-hw2, 2021-12-06 16:45:00 +0800 + LV Status available + # open 1 + LV Size <7.28 TiB + Current LE 1907688 + Segments 1 + Allocation inherit + Read ahead sectors auto + - currently set to 256 + Block device 253:4 + + --- Segments --- + Logical extents 0 to 1907687: + Type linear + Physical volume /dev/md4 + Physical extents 0 to 1907687 +``` + +1. Format the logical volume as ext4 + +``` +mkfs -t ext4 /dev/davidahw2-vg4/lv0 +``` + +2. Create a libvirt x86 64bits Ubuntu 22.04 machine mounting a LVM logical volume + +``` +<controller type='scsi' index='1' model='virtio-scsi'><driver queues='8' iothread='2'/></controller> + + +<disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/davidahw2-vg4/lv0'/> + <target dev='sdd' bus='scsi'/> + <blockio logical_block_size='512' physical_block_size='4096'/> + <address type='drive' controller='1' bus='0' target='1' unit='0'/> +</disk> +``` + + +**On the guest** + +3. Mount libvirt/qemu provided block device /dev/sdd as ext4 partition + +``` +mount /dev/sdd /mnt/test +``` + +4. Write **27G file** or larger **on the guest** causing the **2nd checksum to be different** + +``` +sync; head -c 27G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +8d3b4b263961d2c510390f99879be89b4b9134dc588139ede75573be1590115b myfile +a8e886b3c39d9b4721e582c5e2ca25c76ff6561750ac6dc7aa7e70404661d1cf myfile <== ERROR: Inconsistent checksum +``` + +5. Write **26G file** or larger **on the guest** and **both checksum are the same** + +``` +sync; head -c 26G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile <== CORRECT: Consistent checksum +``` + +**Important**: +- With the VM shutdown, the same commands on the same mounted ext4 partition **on the host** has consistent checksum every time for file sizes from 20G to 40G. +- The disk has no sign of failure (no badblocks reported to the filesystem, MD raid reports a healthy raid setup, smart reports on error) +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1367 b/results/classifier/accel-gemma3:12b/vmm/1367 new file mode 100644 index 000000000..69e1dcfc6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1367 @@ -0,0 +1,6 @@ + +Support MMIO devices in VFIO +Additional information: +- https://lore.kernel.org/qemu-devel/cover.1667542066.git.john.g.johnson@oracle.com/ +- https://github.com/nutanix/libvfio-user +- It also *somewhat* related to supporting non-PCI devices in `ivshmem`: https://gitlab.com/qemu-project/qemu/-/issues/1134 diff --git a/results/classifier/accel-gemma3:12b/vmm/1367365 b/results/classifier/accel-gemma3:12b/vmm/1367365 new file mode 100644 index 000000000..22b30a8ba --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1367365 @@ -0,0 +1,10 @@ + +qemu-img fixed vhd issues + +qemu-img returns fixed vhd images file format to be raw. + +This happens because only the header is seeked for image signatures when getting the image format. In fact, unlike dynamic vhd images, differencing vhds don't have the footer copied in the header. + +An easy fix would be to just search the last 512B for the 'conectix' signature. + +Also, the fixed vhds created by qemu-img seem to be corrupted from Powershell POV. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1368791 b/results/classifier/accel-gemma3:12b/vmm/1368791 new file mode 100644 index 000000000..1f001a6cb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1368791 @@ -0,0 +1,13 @@ + +qemu build fails on Ubuntu 10.04 LTS since recent pixman changes + +Since commit 0dfa7e30126364c434a48cb37a1a41119e536c2a, the qemu git mainline no longer builds on Ubuntu 10.04 LTS. The build fails with: + + CC ui/input.o +ui/qemu-pixman.c: In function 'qemu_pixelformat_from_pixman': +ui/qemu-pixman.c:42: error: 'PIXMAN_TYPE_RGBA' undeclared (first use in this function) +ui/qemu-pixman.c:42: error: (Each undeclared identifier is reported only once +ui/qemu-pixman.c:42: error: for each function it appears in.) +make: *** [ui/qemu-pixman.o] Error 1 + +Andreas Gustafsson, <email address hidden> \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/137 b/results/classifier/accel-gemma3:12b/vmm/137 new file mode 100644 index 000000000..2315baadc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/137 @@ -0,0 +1,2 @@ + +Incompatibility with future VTE will breaks qemu monitor (::commit signal) diff --git a/results/classifier/accel-gemma3:12b/vmm/1374905 b/results/classifier/accel-gemma3:12b/vmm/1374905 new file mode 100644 index 000000000..a492dbb23 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1374905 @@ -0,0 +1,28 @@ + +Pixelation issue in 16-bit color VGA graphics + +What happened: +I ran the 9front installation ISO (here: http://r-36.net/9front/9front-3853.02ebd469f43a.iso.bz2) in QEMU, with a blank qcow2, using `qemu-system-i386 -hda 9front.qcow2.img -cdrom 9front-3853.02ebd469f43a.iso -boot d -vga std -m 1G`. During the console boot, I accept the default display settings (1024x768x16, VESA, PS2 mouse), and 9front proceeds to the GUI boot. However, every pixel is blurred, making text illegible and the GUI unusable. + +What I expected: +Normal pixel rendering / normal display. + +Step by step instructions: +0. Install QEMU 2.1.2 (I use Homebrew's bottle, `brew install qemu`) +1. Download 9front ISO (9front-3853.02ebd469f43a.iso.bz2) +2. Create new QEMU image: `qemu-img create -f qcow2 9front.qcow2.img 20G`. +3. Boot 9front ISO: `qemu-system-i386 -hda 9front.qcow2.img -cdrom 9front-3853.02ebd469f43a.iso -boot d -vga std -m 1G` +4. It displays a console boot screen; accept default args (local, glenda, 1024x768x16, vesa, ps2, etc...) +5. GUI is drawn. +6. Pixel are blurred and unreadable + +Details: +This bug does not occur when 32 bit color is used, using the 1024x768x32. This bug does not occur when QEMU is built with SDL (in Homebrew, `brew install qemu --with-sdl`), although the console portion of 9front's boot runs significantly slower. + +System: +OS X 10.9.5 x86-64 +Macbook Retina Late 2012 +Intel i7 Ivy Bridge dual core. + +Build: +Homebrew's QEMU 2.1.2 bottle, which is build without GTK, SDL, or VDE. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1379688 b/results/classifier/accel-gemma3:12b/vmm/1379688 new file mode 100644 index 000000000..97708624b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1379688 @@ -0,0 +1,6 @@ + +qemu's monitor and parallel create huge window + +I have qemu 2.1. When I try to switch to monitor or parallel0, I get window which is 30 *thousand* pixels in height. It is only gray with no content. This did not happen with previous versions of qemu. + +Kwin crashes because it cannot handle such a huge window. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1384 b/results/classifier/accel-gemma3:12b/vmm/1384 new file mode 100644 index 000000000..bb6e6fdc6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1384 @@ -0,0 +1,2 @@ + +Update libvfio-user to latest upstream diff --git a/results/classifier/accel-gemma3:12b/vmm/1391 b/results/classifier/accel-gemma3:12b/vmm/1391 new file mode 100644 index 000000000..6dbfe010d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1391 @@ -0,0 +1,29 @@ + +virtio-blk: BDRV_REQ_REGISTERED_BUF optimization hint crashes on macOS +Description of problem: +When using QEMU 7.2.0 on macOS with the virtio-blk drive, the process will exit and QMP shows a `BLOCK_IO_ERROR` event. This appears to be caused by this line: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/block/virtio-blk.c#L405 introduced in https://gitlab.com/qemu-project/qemu/-/commit/baf422684d73c7bf38e2c18815e18d44fcf395b6 + +Commenting that line out fixes the issue. +Steps to reproduce: +1. Run the QEMU command above with a Ubuntu 22.04 server ISO image. +2. Follow the installer and try to get to the end. +3. The process will crash before you can finish installing. +Additional information: +Following event appears on QMP: +``` +{ + data = { + action = report; + device = "drive437EC806-41A4-4CCE-A747-713352E7C27C"; + "node-name" = "#block785"; + nospace = 0; + operation = write; + reason = "Invalid argument"; + }; + event = "BLOCK_IO_ERROR"; + timestamp = { + microseconds = 808474; + seconds = 1671867673; + }; +} +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1392468 b/results/classifier/accel-gemma3:12b/vmm/1392468 new file mode 100644 index 000000000..33f87b60d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1392468 @@ -0,0 +1,6 @@ + +qemu uses a bitmap icon + +qemu currently uses the icon in pc-bios/qemu-icon.bmp, which, obviously, is a bitmap file. It is loaded such that white pixels will be transparent. This can cause nasty artifacts in the display. + +Unless there is a specific reason to use bitmaps, I'd suggest moving to, e.g., a PNG file with a proper alpha channel. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1396 b/results/classifier/accel-gemma3:12b/vmm/1396 new file mode 100644 index 000000000..16443e1d9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1396 @@ -0,0 +1,4 @@ + +Is it possible to emulate QEMU 64 Bit on Windows? +Description of problem: +Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `. diff --git a/results/classifier/accel-gemma3:12b/vmm/1396052 b/results/classifier/accel-gemma3:12b/vmm/1396052 new file mode 100644 index 000000000..f9a62df14 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1396052 @@ -0,0 +1,65 @@ + +migration failed when running BurnInTest in guest + +Hi, +I found a live migration problem and have found out the reason, but I can't fix it up myself. I really need help. +When live migration vm and it's block device in save time, it will occur probabilistic . + +Step: +1. start a windows vm,and run burnInTest(it will write dirty data to block device in migration) +2. migrate vm with it's block device. +3. a few minutes later, dest vm was killed and migration will be failed (probabilistic ) + +Reason: + when migraion start, in source host libvirt will send command to qemu,and qemu will call mirror_run coroutine to copy blcok device data to dest vm block device. mirror_run running in qemu main thread. When this finished(actually it still running because in following steps,there may generate dirty data by vm), qemu will start migration_thread to migration ram and other device. + In dest vm, qemu will call "bdrv_invalidate_cache --> qcow2_invalidate_cache" function after vm read "QEMU_VM_EOF" byte. qcow2_invalidate_cache fuction call qcow2_close , in qcow2_close fuction set "s->l1_table = NULL" and then call qcow2_cache_flush fuction. In qcow2_cache_flush fuction will call "bdrv_flush-->bdrv_flush_co_entry-->bdrv_co_flush-->qemu_coroutine_yield". This will let itself back to mian loop. If source vm send block device dirty data to dest vm at this time, in dest vm will occur the following segmentation fault. + The primary reason is mirror_run and migration run in two thread. although qemu stopping vm before write "QEMU_VM_EOF" byte, it still can't ensure mirror_run coroutine do not write dirty data after migration thread sending "QEMU_VM_EOF" byte. + + +Program received signal SIGSEGV, Segmentation fault. +0x00007f90d250db24 in get_cluster_table (bs=0x7f90d493f500, offset=1832189952, new_l2_table=0x7f8fbd6faa88, + new_l2_index=0x7f8fbd6faaa0) at block/qcow2-cluster.c:573 +573 l2_offset = s->l1_table[l1_index] & L1E_OFFSET_MASK; +(gdb) bt +#0 0x00007f90d250db24 in get_cluster_table (bs=0x7f90d493f500, offset=1832189952, new_l2_table=0x7f8fbd6faa88, + new_l2_index=0x7f8fbd6faaa0) at block/qcow2-cluster.c:573 +#1 0x00007f90d250e577 in handle_copied (bs=0x7f90d493f500, guest_offset=1832189952, host_offset=0x7f8fbd6fab18, + bytes=0x7f8fbd6fab20, m=0x7f8fbd6fabc8) at block/qcow2-cluster.c:927 +#2 0x00007f90d250ef45 in qcow2_alloc_cluster_offset (bs=0x7f90d493f500, offset=1832189952, num=0x7f8fbd6fabfc, + host_offset=0x7f8fbd6fabc0, m=0x7f8fbd6fabc8) at block/qcow2-cluster.c:1269 +#3 0x00007f90d250445f in qcow2_co_writev (bs=0x7f90d493f500, sector_num=3578496, remaining_sectors=2040, + qiov=0x7f8fbd6fae90) at block/qcow2.c:1171 +#4 0x00007f90d24d4764 in bdrv_aligned_pwritev (bs=0x7f90d493f500, req=0x7f8fbd6facd0, offset=1832189952, bytes=1044480, + qiov=0x7f8fbd6fae90, flags=0) at block.c:3321 +#5 0x00007f90d24d4d21 in bdrv_co_do_pwritev (bs=0x7f90d493f500, offset=1832189952, bytes=1044480, qiov=0x7f8fbd6fae90, + flags=0) at block.c:3447 +#6 0x00007f90d24d3115 in bdrv_rw_co_entry (opaque=0x7f8fbd6fae10) at block.c:2710 +#7 0x00007f90d24d31e7 in bdrv_prwv_co (bs=0x7f90d493f500, offset=1832189952, qiov=0x7f8fbd6fae90, is_write=true, flags=0) + at block.c:2746 +#8 0x00007f90d24d32eb in bdrv_rw_co (bs=0x7f90d493f500, sector_num=3578496, + buf=0x7f90d4e3d400 "\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312", <incomplete sequence \313>..., nb_sectors=2040, is_write=true, flags=0) at block.c:2776 +#9 0x00007f90d24d3429 in bdrv_write (bs=0x7f90d493f500, sector_num=3578496, + buf=0x7f90d4e3d400 "\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312", <incomplete sequence \313>..., nb_sectors=2040) at block.c:2810 +#10 0x00007f90d24cc2b5 in nbd_trip (opaque=0x7f90d4ba9aa0) at nbd.c:1191 +#11 0x00007f90d24e86fb in coroutine_trampoline (i0=-725586416, i1=32656) at coroutine-ucontext.c:118 +#12 0x00007f90d0449310 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#13 0x00007fff3fcfda10 in ?? () +#14 0x0000000000000000 in ?? () +(gdb) p bs +$1 = (BlockDriverState *) 0x7f90d493f500 +(gdb) p *s +$3 = {cluster_bits = 16, cluster_size = 65536, cluster_sectors = 128, l2_bits = 13, l2_size = 8192, l1_size = 40, + l1_vm_state_index = 40, csize_shift = 54, csize_mask = 255, cluster_offset_mask = 18014398509481983, + l1_table_offset = 196608, l1_table = 0x0, l2_table_cache = 0x7f90d493eee0, refcount_block_cache = 0x7f90d493ef30, + cluster_cache = 0x7f90d4a84350 "", cluster_data = 0x7f90ce4de010 "", cluster_cache_offset = 18446744073709551615, + cluster_allocs = {lh_first = 0x0}, refcount_table = 0x7f90d4a94360, refcount_table_offset = 65536, + refcount_table_size = 8192, free_cluster_index = 209420, free_byte_offset = 0, lock = {locked = true, queue = {entries = { + tqh_first = 0x0, tqh_last = 0x7f90d4942c60}}}, crypt_method = 0, crypt_method_header = 0, aes_encrypt_key = { + rd_key = {0 <repeats 60 times>}, rounds = 0}, aes_decrypt_key = {rd_key = {0 <repeats 60 times>}, rounds = 0}, + snapshots_offset = 0, snapshots_size = 0, nb_snapshots = 0, snapshots = 0x0, flags = 10338, qcow_version = 3, + use_lazy_refcounts = false, refcount_order = 4, discard_passthrough = {false, true, false, true, false}, + overlap_check = 127, incompatible_features = 0, compatible_features = 0, autoclear_features = 0, + unknown_header_fields_size = 0, unknown_header_fields = 0x0, unknown_header_ext = {lh_first = 0x0}, discards = { + tqh_first = 0x0, tqh_last = 0x7f90d4942ec8}, cache_discards = false} +(gdb) p s->l1_table +$4 = (uint64_t *) 0x0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1399 b/results/classifier/accel-gemma3:12b/vmm/1399 new file mode 100644 index 000000000..b60e74100 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1399 @@ -0,0 +1,73 @@ + +Early faults when direct booting large Linux kernel images on x86_64 and aarch64 guests. +Description of problem: +When attempting to load a Linux kernel image for direct boot via the `-kernel` command line option, a triple fault occurs shortly after attempting to hand off execution to the kernel if the kernel image is ‘large’ in size (this can be easily reproduced with a custom kernel build by embedding an initramfs in the kernel that includes a few large but mostly incompressible files). I’m not certain of the exact cutoff, but a 75 MB kernel image on x86_64, and a 67 MB kernel image on AArch64 both exhibit the issue, while a 13 MB kernel image on x86_64 does not. +Steps to reproduce: +1. Attempt to direct boot an exceptionally large kernel image as an x86_64 or aarch64 guest. +Additional information: +I have not yet been able to track down exactly where the initial fault is happening, and am not even certain that it’s in Linux’s early boot code, but the fact that this is reproducible across multiple architectures and is unaffected by things like KASLR and the exact compression algorithm for the guest kernel suggests to me that it’s more likely to be an issue in QEMU’s loader code for direct kernel boot than in the Linux kernel itself. + +Running on x86_64, the initial fault appears to be a general protection fault, followed by a double and then triple fault. Output from running QEMU as above with `-d int,guest_error -no-reboot’: + +``` +check_exception old: 0xffffffff new 0xd + 0: v=0d e=0000 i=0 cpl=0 IP=0010:000000000789f7f0 pc=000000000789f7f0 SP=0018:00000000078e6fd8 env->regs[R_EAX]=0000000000000000 +RAX=0000000000000000 RBX=6fb84fe3052f53e2 RCX=00000000fb600000 RDX=00000000078fbed0 +RSI=00000000078f6000 RDI=00000000078e80e0 RBP=00000000078e80e0 RSP=00000000078e6fd8 +R8 =00000000078fb000 R9 =00000000fb600000 R10=000fffffffe00000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=000000000789f7f0 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-] +SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0000 0000000000000000 00000000 00000000 +GS =0000 0000000000000000 00000000 00000000 +LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT +TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl +GDT= 00000000078b1030 0000002f +IDT= 00000000078b1070 000001ff +CR0=80050033 CR2=6fb84fe3052f53ee CR3=00000000078f6000 CR4=00000020 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=0000000000000018 CCD=6fb84fe3052f53e2 CCO=LOGICQ +EFER=0000000000000500 +check_exception old: 0xd new 0xd + 1: v=08 e=0000 i=0 cpl=0 IP=0010:000000000789f7f0 pc=000000000789f7f0 SP=0018:00000000078e6fd8 env->regs[R_EAX]=0000000000000000 +RAX=0000000000000000 RBX=6fb84fe3052f53e2 RCX=00000000fb600000 RDX=00000000078fbed0 +RSI=00000000078f6000 RDI=00000000078e80e0 RBP=00000000078e80e0 RSP=00000000078e6fd8 +R8 =00000000078fb000 R9 =00000000fb600000 R10=000fffffffe00000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=000000000789f7f0 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-] +SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0000 0000000000000000 00000000 00000000 +GS =0000 0000000000000000 00000000 00000000 +LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT +TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl +GDT= 00000000078b1030 0000002f +IDT= 00000000078b1070 000001ff +CR0=80050033 CR2=6fb84fe3052f53ee CR3=00000000078f6000 CR4=00000020 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=0000000000000018 CCD=6fb84fe3052f53e2 CCO=LOGICQ +EFER=0000000000000500 +check_exception old: 0x8 new 0xd +``` + +Running on AArch64, the emulated CPU gets stuck in a loop trying to handle ‘exception 5’, showing the following output when run as above with `-d int, guest_error -no-reboot`, repeated infinitely until the emulator gets killed: + +``` +Taking exception 5 [IRQ] on CPU 0 +...from EL1 to EL1 +...with ESR 0x15/0x56000000 +...with ELR 0xffffffef0dee4098 +...to EL1 PC 0xffffffef0d810a80 PSTATE 0x3c5 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffffef0dee4098 +``` + +I have also attempted to reproduce this on 64-bit little-endian POWER using qemu-system-ppc64 and an equivalent kernel config, and was _not_ able to reproduce it there with a 69 MB kernel image. + +I can provide Linux kernel configs for the affected kernels upon request, but am not (currently) able to provide full system images (the project I was working on when I came across this is not yet public). diff --git a/results/classifier/accel-gemma3:12b/vmm/1399191 b/results/classifier/accel-gemma3:12b/vmm/1399191 new file mode 100644 index 000000000..23df7bda2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1399191 @@ -0,0 +1,40 @@ + +Large VHDX image size + +We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + +Why is that the VHDX generates large sized images for both the formats? + +The following commands were used to convert the vmdk image to VHDX format + +1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk Test-fixed.vhdx + +qemu-img info Test-fixed.vhdx +image: Test-fixed.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + + + +2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + +qemu-img info Test-dynamic.vhdx +image: Test-dynamic.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + +We tried this with the following version of qemu +1. qemu-2.0.0 +2. qemu-2.1.2 +3. qemu-2.2.0-rc4 + + +Please let us know how to create compact VHDX images using qemu-img. +Thank you \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1399943 b/results/classifier/accel-gemma3:12b/vmm/1399943 new file mode 100644 index 000000000..1e8cf2c65 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1399943 @@ -0,0 +1,29 @@ + +qemu-system-sparc loses serial console data on EAGAIN + +When running a guest OS with a serial console under +"qemu-system-sparc -nographic", parts of the serial console output +are sometimes lost. + +This happens when a write() to standard output by qemu returns EAGAIN, +as may be the case when the guest is generating console output faster +than the tty (or pty/pipe/socket, etc.) connected to qemu's standard +output accepts it. The bug affects all releases of qemu since 1.5, +which was the first version to set stdout to O_NONBLOCK mode. Version +1.4.2 and earlier work correctly. + +To reproduce the bug, you will need a guest OS configured with a +serial console, and a host with a slow tty. The attached shell script +"sparc-test.sh" does this by using Aboriginal Linux as the serial +console guest, and a pty controlled by a Python script and the +"pexpect" Python module as the slow tty. A "seq" command is sent +to the guest to generate 100,000 lines of output containing sequential +integers, and the output is checked for gaps. The script limits the +tty output rate by occasionally sleeping for 1/10 of a second. + +This bug was originally reported against qemu-system-i386 as +bug #1335444, and has since been fixed in qemu-system-i386, +but remains in qemu-system-sparc as of today's git sources +(d00e6cddc220de993573dfb5fd160ac72ccd49ab). I am opening +this separate bug for the sparc case because I was asked +to do so by Paolo Bonzini in #1335444. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1399957 b/results/classifier/accel-gemma3:12b/vmm/1399957 new file mode 100644 index 000000000..9dc807abe --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1399957 @@ -0,0 +1,13 @@ + +Strange colors on PowerMac Machine OsX + +Strange colors on PowerMac Machine OsX +if it used VmWare or Std i have strange color palette as result. +I had benn made a grab of screen here + +http://i1249.photobucket.com/albums/hh511/tlosm/qyellow_zps1d2dfc18.jpg + +My Machine is a PowerMac G5 Quad with Nvidia 7800Gtx 512mb + +thankyou +Luigi \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1405176 b/results/classifier/accel-gemma3:12b/vmm/1405176 new file mode 100644 index 000000000..6fa600358 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1405176 @@ -0,0 +1,6 @@ + +ctrl+alt+2 not work on gtk display + +I download 2.2.0 release on http://wiki.qemu.org/Download +the monitor console does not appear in gtk display but works for sdl and vnc. +my gtk is 3.12.2 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1410 b/results/classifier/accel-gemma3:12b/vmm/1410 new file mode 100644 index 000000000..d383d0c4d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1410 @@ -0,0 +1,15 @@ + +system_powerdown only works once +Description of problem: +When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume. The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path. + +There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either. +Steps to reproduce: + +1. Boot a guest configured to sleep when it receives a power button event +2. `system_powerdown` from the monitor to tell it to sleep +3. `info status` to verify that it is suspended +4. Wake the guest, either with `system_wakeup` or moving the mouse or something +5. `system_powerdown` has no effect +Additional information: +This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough. diff --git a/results/classifier/accel-gemma3:12b/vmm/1414 b/results/classifier/accel-gemma3:12b/vmm/1414 new file mode 100644 index 000000000..e2f39943c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1414 @@ -0,0 +1,21 @@ + +Configure script fix for glib version +Description of problem: +Script "configure" uses "pkg-config" directly, at line 2420: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420 + +Because of it, GLIB_VERSION in "config-host.mak" can be taken from host system, under some circumstances (if PKG_CONFIG_PATH is not defined). + +In case of cross-compilation, "**$pkg_config**" should be used instead of "pkg-config", to use pkg-config from cross-compilation toolchain and to take GLIB_VERSION of cross-compiled glib (as it is **correctly used at line 1476**: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L1476 ). +Steps to reproduce: +1. Do not define PKG_CONFIG_PATH environment variable, use PKG_CONFIG variable instead. +2. Try to ./configure with cross-compiled glib. +3. GLIB_VERSION in config-host.mak will be from host glib. +Additional information: +Change lihe 2420:<br> +https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420 +<br> +echo "GLIB_VERSION=$(**pkg-config** --modversion glib-2.0)" >> $config_host_mak +<br>to:<br> +echo "GLIB_VERSION=$(**\$pkg_config** --modversion glib-2.0)" >> $config_host_mak + +P.s. Sorry for posting the patch here, GitLab requires signing with a key to push the commit, it's too complicated to post 2-bytes fix. diff --git a/results/classifier/accel-gemma3:12b/vmm/1414222 b/results/classifier/accel-gemma3:12b/vmm/1414222 new file mode 100644 index 000000000..3741f982f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1414222 @@ -0,0 +1,21 @@ + +qemu-system-i386: -vnc localhost:0,to=99,id=default: Invalid parameter 'to' + +git-bisect pints to: + +4db14629c38611061fc19ec6927405923de84f08 is the first bad commit +commit 4db14629c38611061fc19ec6927405923de84f08 +Author: Gerd Hoffmann <email address hidden> +Date: Tue Sep 16 12:33:03 2014 +0200 + + vnc: switch to QemuOpts, allow multiple servers + + This patch switches vnc over to QemuOpts, and it (more or less + as side effect) allows multiple vnc server instances. + + Signed-off-by: Gerd Hoffmann <email address hidden> + +:040000 040000 70020c79b463eaff4b91c8c7f985240d1d1914f0 354a3a125e7b82a1699ce4e0cfc5055662bd3466 M include +:100644 100644 0b4f131936052ed6062ba4b2b9434da0c2cce959 963305c26917a930f37d916df66b319d6558d281 M qmp.c +:040000 040000 e7933d52124ae48100893eed8e14cbe46f80b936 30fa5966f5c8362d6db6730a7091bbde7780d4d8 M ui +:100644 100644 9fb32c13df1c14daf8304184c6503d16bff7afce 983259bc9f7064b446da358a316a31a31731a223 M vl.c \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/142 b/results/classifier/accel-gemma3:12b/vmm/142 new file mode 100644 index 000000000..9265cb93c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/142 @@ -0,0 +1,2 @@ + +qemu -readconfig/-writeconfig cannot handle quotes in values diff --git a/results/classifier/accel-gemma3:12b/vmm/1425597 b/results/classifier/accel-gemma3:12b/vmm/1425597 new file mode 100644 index 000000000..e084138ab --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1425597 @@ -0,0 +1,15 @@ + +moving window + changing screen resolution = bug + +Steps to reproduce: +1. Run qemu (sdl) +2. Start moving the window +3. At that moment the virtualized OS should change its screen resolution (for example, when switching from initial qemu screen to grub) + +What I see: +Window size doesn't change, but internal screen resolution changes, so, image scale stops to be 1:1, now I see virtualized OS in wrong scale. + +What I expected to see: +Window size changes so, that it keeps synchronized with internal resolution (as usual) + +This bug preserves at lastest git version at the moment, i. e. 3d30395f7fb3315e4ecf0de4e48790e1326bbd47 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1429034 b/results/classifier/accel-gemma3:12b/vmm/1429034 new file mode 100644 index 000000000..f628702a0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1429034 @@ -0,0 +1,21 @@ + +qemu abort in qemu_coroutine_enter when multi-thread writing + +qemu release version: 2.2.0 +platform: x86_64 + +qemu would be aborted when there are two threads to write two seperate qcow2 files. + +call stack: + +#0 0x7ffff5e18989 __GI_raise(sig=sig@entry=6) (../nptl/sysdeps/unix/sysv/linux/raise.c:56) +#1 0x7ffff5e1a098 __GI_abort() (abort.c:90) +#2 0x7ffff728c034 qemu_coroutine_enter(co=0x7fffe0004800, opaque=0x0) (qemu-coroutine.c:117) +#3 0x7ffff727df39 bdrv_co_io_em_complete(opaque=0x7ffff7fd6ae0, ret=0) (block.c:4847) +#4 0x7ffff7270314 thread_pool_completion_bh(opaque=0x7fffe0006ad0) (thread-pool.c:187) +#5 0x7ffff726f873 aio_bh_poll(ctx=0x7fffe0001d00) (async.c:82) +#6 0x7ffff728340b aio_dispatch(ctx=0x7fffe0001d00) (aio-posix.c:137) +#7 0x7ffff72837b0 aio_poll(ctx=0x7fffe0001d00, blocking=true) (aio-posix.c:248) +#8 ?? 0x00007ffff72795a8 in bdrv_prwv_co (bs=0x7fffdc0021c0, offset=12071639552, qiov=0x7fffe67fa590, is_write=true, flags=(unknown: 0)) (block.c:2703) +#9 ?? 0x00007ffff727966a in bdrv_rw_co (bs=0x7fffdc0021c0, sector_num=23577421, buf=0x7fffe4629250 "\234\b\335Ǽ\254\213q\301\366\315=\005oI\301\245=\373\004+2?H\212\025\035+\262\274C;X\301FaP\324\335\061ҝ&Y\316=\347\335\020\365\003goɿ\214\312S=\v2]\373\363C\311\341\334\r5k\346k\204\332\023\264\315陌\230\203J\222u\214\066", nb_sectors=128, is_write=true, flags=(unknown: 0)) (block.c:2726) +#10 0x7ffff7279758 bdrv_write(bs=0x7fffdc0021c0, sector_num=23577421, buf=0x7fffe4629250 "\234\b\335Ǽ\254\213q\301\366\315=\005oI\301\245=\373\004+2?H\212\025\035+\262\274C;X\301FaP\324\335\061ҝ&Y\316=\347\335\020\365\003goɿ\214\312S=\v2]\373\363C\311\341\334\r5k\346k\204\332\023\264\315陌\230\203J\222u\214\066", nb_sectors=128) (block.c:2760) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1432 b/results/classifier/accel-gemma3:12b/vmm/1432 new file mode 100644 index 000000000..6e9348da9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1432 @@ -0,0 +1,25 @@ + +meson prints "Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12." for every test +Description of problem: +Run 'make check V=1' and observe that every test causes an warning message about an unknown TAP version + +``` +>>> G_TEST_SRCDIR=/home/berrange/src/virt/qemu/tests/unit MALLOC_PERTURB_=61 G_TEST_BUILDDIR=/home/berrange/src/virt/qemu/build/tests/unit /home/berrange/src/virt/qemu/build/tests/unit/test-shift128 --tap -k +▶ 22/44 /host-utils/test_lshift OK +▶ 22/44 /host-utils/test_rshift OK +22/44 qemu:unit / test-shift128 OK 0.01s 2 subtests passed + +Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12. + +``` + +This message comes from inside meson + +``` +$ rpm -ql meson | xargs grep 'Unknown TAP version' 2>/dev/null +/usr/lib/python3.11/site-packages/mesonbuild/mtest.py: self.warnings.append('Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12.') +``` + +This is with meson-1.0.0-1.fc38.noarch +Steps to reproduce: +1. make check V=1 diff --git a/results/classifier/accel-gemma3:12b/vmm/1445 b/results/classifier/accel-gemma3:12b/vmm/1445 new file mode 100644 index 000000000..1c4e25c4a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1445 @@ -0,0 +1,128 @@ + +Negative-size-param in nand_blk_load_512() +Description of problem: +Found a way to trigger negative-size-param when calling memcpy in +nand_blk_load_512() called by nand_getio(). Specifically, the offset can +be larger than NAND_PAGE_SIZE + OOB_SIZE, e.g., 0x211. + +``` c + if (s->blk) { + // ... + } else { + memcpy(s->io, s->storage + PAGE_START(s->addr) + + // offset=0x211 + offset, NAND_PAGE_SIZE + OOB_SIZE - offset); + s->ioaddr = s->io; + } +``` +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine tosa -monitor none -serial none \ +-display none -qtest stdio +write 0x10000104 0x1 0x7f +write 0x10000111 0x1 0x52 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +write 0x10005204 0x1 0x15 +write 0x10005201 0x1 0x70 +write 0x10005202 0x1 0x50 +read 0x10005203 0x1 +read 0x10005203 0x1 +EOF +``` +Additional information: +``` +=20435==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5645f46c0ac0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3601248722 +INFO: Loaded 1 modules (601321 inline 8-bit counters): 601321 [0x5645f75ae000, 0x5645f7640ce9), +INFO: Loaded 1 PC tables (601321 PCs): 601321 [0x5645f6c801e0,0x5645f75ad070), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *tc6393xb* +This process will fuzz the following MemoryRegions: + * tc6393xb.vram[0] (size 100000) + * tc6393xb[0] (size 10000) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * tc6393xb.vram, EVENT_TYPE_MMIO_READ, 0x10100000 +0x100000, 1,4 + * tc6393xb.vram, EVENT_TYPE_MMIO_WRITE, 0x10100000 +0x100000, 1,4 + * tc6393xb, EVENT_TYPE_MMIO_READ, 0x10000000 +0x10000, 1,1 + * tc6393xb, EVENT_TYPE_MMIO_WRITE, 0x10000000 +0x10000, 1,1 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 280Mb +Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb-crash-55c2b01921c18ce020fa35319af4632834e116be.minimized +================================================================= +==20435==ERROR: AddressSanitizer: negative-size-param: (size=-1) + #0 0x5645effd2656 in __asan_memcpy /root/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 + #1 0x5645f040b342 in nand_blk_load_512 /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:794:9 + #2 0x5645f03f1f64 in nand_getio /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:601:9 + #3 0x5645f08acc9a in tc6393xb_nand_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:359:20 + #4 0x5645f08a53fc in tc6393xb_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:500:21 + #5 0x5645f36b308b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11 + #6 0x5645f3673391 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #7 0x5645f367075c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16 + #8 0x5645f366fe98 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9 + #9 0x5645f36ec09d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23 + #10 0x5645f36ed6a8 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12 + #11 0x5645f36ed168 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18 + #12 0x5645f000e7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18 + #13 0x5645f000e7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1017:5 + #14 0x5645f000d97e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1041:35 + #15 0x5645f46bc47f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #16 0x5645f46b37fb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #17 0x5645f46b36d0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #18 0x5645f00240fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #19 0x5645f46c0d62 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #20 0x5645eff05816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #21 0x5645efee8444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #22 0x5645efef33ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #23 0x5645efedf9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #24 0x7fbc03b97082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #25 0x5645efedfa2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb+0x300ea2d) + +0x7fbbf45ffa11 is located 529 bytes inside of 69206016-byte region [0x7fbbf45ff800,0x7fbbf87ff800) +allocated by thread T0 here: + #0 0x5645effd36cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 + #1 0x7fbc04e4ee98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + #2 0x5645f3a1bdcb in device_set_realized /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:553:13 + #3 0x5645f3a53a6b in property_set_bool /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:2273:5 + #4 0x5645f3a4c99d in object_property_set /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:1408:5 + #5 0x5645f3a60329 in object_property_set_qobject /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/qom-qobject.c:28:10 + #6 0x5645f3a4d6fd in object_property_set_bool /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:1477:15 + #7 0x5645f3a0d5c2 in qdev_realize /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:333:12 + #8 0x5645f03f3f30 in nand_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:646:5 + #9 0x5645f08a44c2 in tc6393xb_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:558:16 + #10 0x5645f27b7822 in tosa_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/arm/tosa.c:250:12 + #11 0x5645f05dc5d7 in machine_run_board_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/machine.c:1400:5 + #12 0x5645f2269aab in qemu_init_board /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2485:5 + #13 0x5645f22697bc in qmp_x_exit_preconfig /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2581:5 + #14 0x5645f2270d3f in qemu_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:3584:9 + #15 0x5645f00223f3 in LLVMFuzzerInitialize /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1761:5 + #16 0x5645efeeffab in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:664:29 + #17 0x5645efedf9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #18 0x7fbc03b97082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: negative-size-param /root/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy +==20435==ABORTING +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1445633 b/results/classifier/accel-gemma3:12b/vmm/1445633 new file mode 100644 index 000000000..7a24462f6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1445633 @@ -0,0 +1,14 @@ + +Creating a passthrough USB device causes excessive CPU usage in the guest + +My host machine is a Lenovo X1 Carbon (3rd gen) laptop running 64-bit Ubuntu Linux 14.04. My guest machine is running 64-bit Ubuntu Linux 12.04. My QEMU was compiled moments ago from the git repository, and it says its version is: +qemu-x86_64 version 2.2.93, Copyright (c) 2003-2008 Fabrice Bellard + +My issue is that when I create a passthrough for a USB host device to the guest, it causes qemu's CPU utilization on the host to increase significantly and stay there. After the passthrough is created, qemu's CPU usage in top hovers between 20% and 30% (evenly spread across CPUs). In virt-manager's CPU usage chart, it shows the guest's CPU usage growing from 0% to about 5%, although running "top" in the guest does not show an increase in CPU usage. These usage levels drop back down to normal (0 to 1%) only after I physically unplug the device or remove the passthrough mapping. + +It doesn't seem to matter what the device is. I have tested it using: +A Realtek rtl8192cu-based 802.11n adapter +An HP optical mouse +A Samsung Galaxy S5 phone + +The behavior is the same regardless of device, and they otherwise seem to work properly in the guest machine. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1450891 b/results/classifier/accel-gemma3:12b/vmm/1450891 new file mode 100644 index 000000000..3224763bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1450891 @@ -0,0 +1,17 @@ + +VM will not resume on GlusterFS + +oVirt uses libvirt to run QEMU. +Images are passed to QEMU as files, not file descriptors. +When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted. +In this case, the VM goes into paused state. +When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a: +"block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)". + +Please check file-descriptors and reopen image file on 'cont' event in QEMU. +Thanks. + +References: + +[1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html +[2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1452742 b/results/classifier/accel-gemma3:12b/vmm/1452742 new file mode 100644 index 000000000..7e46c520b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1452742 @@ -0,0 +1,10 @@ + +the option for vdagent communication needed for qxl scren resizing is not documented + +Hello, + +I tried running a guest with vdagent which is supposed to resize the guest screen to match client window size. + +However, a special serial port needs to be created for the vdagent to communicate with the client. + +This patch adds a short note to the vga qxl option. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1452904 b/results/classifier/accel-gemma3:12b/vmm/1452904 new file mode 100644 index 000000000..6d46bab18 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1452904 @@ -0,0 +1,209 @@ + +High CPU in idle Windows guest + +Hi, + +I'm running a freshly installed Windows 7 domU on an up-to-date Debian +jessie machine running Xen 4.4.1-9. When the Windows machine is idle, +I'm seeing upwards of 10% CPU usage from the qemu-system-i386 instance. +Other Linux and FreeBSD machines register negligable CPU usage (<0.5%). +The server is an HP Proliant DL360 G7. + +Data from perf attacthed to the process might give the best clues. + +Any information as to why this processes is comsuming so much CPU would +be much appreciated. + +Regards, +Terry. + +# uname -a +Linux xen 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux + +# lsb_release -a +No LSB modules are available. +Distributor ID: Debian +Description: Debian GNU/Linux 8.0 (jessie) +Release: 8.0 +Codename: jessie + +# qemu-system-i386 --version +QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11), Copyright (c) 2003-2008 Fabrice Bellard + +# cat win7.cfg +name = 'win7' +vcpus = '1' +memory = '4096' +builder = 'hvm' +disk = [ '/vms/xen/domains/desk_win7/disk1.img,qcow2,hda,rw', + '/vms/xen/domains/desk_win7/disk2.img,qcow2,hdb,rw' ] +vfb = [ 'vnc=1,vnclisten="0.0.0.0",sdl=0' ] +vif = [ 'mac=00:16:3E:FB:FC:39,bridge=xenbr0' ] +serial = 'pty' +vnc = 1 +vnclisten = '0.0.0.0' +sdl = 0 +usbdevice = 'mouse' +audio = 1 +soundhw = 'sb16,es1370' +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'restart' + +# /usr/bin/qemu-system-i386 -nodefaults -name desk_win7 -boot order=cda -usb -usbdevice mouse -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:fb:fc:39 -netdev type=tap,id=net0,ifname=vif12.0-emu,script=no,downscript=no -m 4088 -drive file=/vms/xen/domains/desk_win7/disk1.img,if=ide,index=0,media=disk,format=qcow2,cache=writeback -drive file=/vms/xen/domains/desk_win7/disk2.img,if=ide,index=1,media=disk,format=qcow2,cache=writeback -vnc 0.0.0.0:0,to=99 -display none -device cirrus-vga -global vga.vram_size_mb=8 + +# top +Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie +%Cpu(s): 16.6 us, 5.5 sy, 0.0 ni, 0.0 id, 77.9 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem: 354420 total, 348884 used, 5536 free, 184 buffers +KiB Swap: 17575932 total, 2642868 used, 14933064 free. 4132 cached Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +12297 root 20 0 6683864 192944 1140 S 20.6 54.4 2:25.51 qemu-syste+ + +# xen dmesg +(XEN) Xen version 4.4.1 (Debian 4.4.1-9) (<email address hidden>) (gcc (Debian 4.9.2-10) 4.9.2) debug=n Mon Apr 6 18:24:28 UTC 2015 +(XEN) Bootloader: GRUB 2.02~beta2-22 +(XEN) Command line: placeholder dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin radeon.modeset=0 iommu=no-intremap +(XEN) Video information: +(XEN) VGA is text mode 80x25, font 8x16 +(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds +(XEN) EDID info not retrieved because no DDC retrieval method detected +(XEN) Disc information: +(XEN) Found 1 MBR signatures +(XEN) Found 1 EDD information structures +(XEN) Xen-e820 RAM map: +(XEN) 0000000000000000 - 000000000009f400 (usable) +(XEN) 000000000009f400 - 00000000000a0000 (reserved) +(XEN) 00000000000f0000 - 0000000000100000 (reserved) +(XEN) 0000000000100000 - 00000000cf62f000 (usable) +(XEN) 00000000cf62f000 - 00000000cf63c000 (ACPI data) +(XEN) 00000000cf63c000 - 00000000cf63d000 (usable) +(XEN) 00000000cf63d000 - 00000000d4000000 (reserved) +(XEN) 00000000fec00000 - 00000000fee10000 (reserved) +(XEN) 00000000ff800000 - 0000000100000000 (reserved) +(XEN) 0000000100000000 - 00000004affff000 (usable) +(XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP ) +(XEN) ACPI: XSDT CF630140, 00B4 (r1 HP ProLiant 2 Ò 162E) +(XEN) ACPI: FACP CF630240, 00F4 (r3 HP ProLiant 2 Ò 162E) +(XEN) ACPI: DSDT CF630340, 20BD (r1 HP DSDT 1 INTL 20030228) +(XEN) ACPI: FACS CF62F100, 0040 +(XEN) ACPI: SPCR CF62F140, 0050 (r1 HP SPCRRBSU 1 Ò 162E) +(XEN) ACPI: MCFG CF62F1C0, 003C (r1 HP ProLiant 1 0) +(XEN) ACPI: HPET CF62F200, 0038 (r1 HP ProLiant 2 Ò 162E) +(XEN) ACPI: FFFF CF62F240, 0064 (r2 HP ProLiant 2 Ò 162E) +(XEN) ACPI: SPMI CF62F2C0, 0040 (r5 HP ProLiant 1 Ò 162E) +(XEN) ACPI: ERST CF62F300, 01D0 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: APIC CF62F500, 015E (r1 HP ProLiant 2 0) +(XEN) ACPI: SRAT CF62F680, 0570 (r1 HP Proliant 1 Ò 162E) +(XEN) ACPI: FFFF CF62FC00, 0176 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: BERT CF62FD80, 0030 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: HEST CF62FDC0, 00BC (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: DMAR CF62FE80, 0150 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: SSDT CF632400, 0125 (r3 HP CRSPCI0 2 HP 1) +(XEN) ACPI: SSDT CF632540, 01CF (r3 HP riser1a 2 INTL 20061109) +(XEN) ACPI: SSDT CF632740, 03BB (r1 HP pcc 1 INTL 20090625) +(XEN) ACPI: SSDT CF632B00, 0377 (r1 HP pmab 1 INTL 20090625) +(XEN) ACPI: SSDT CF632E80, 2094 (r1 INTEL PPM RCM 1 INTL 20061109) +(XEN) System RAM: 18421MB (18863928kB) +(XEN) Domain heap initialised +(XEN) Processor #0 6:12 APIC version 21 +(XEN) Processor #16 6:12 APIC version 21 +(XEN) Processor #4 6:12 APIC version 21 +(XEN) Processor #20 6:12 APIC version 21 +(XEN) Processor #2 6:12 APIC version 21 +(XEN) Processor #18 6:12 APIC version 21 +(XEN) Processor #1 6:12 APIC version 21 +(XEN) Processor #17 6:12 APIC version 21 +(XEN) Processor #5 6:12 APIC version 21 +(XEN) Processor #21 6:12 APIC version 21 +(XEN) Processor #3 6:12 APIC version 21 +(XEN) Processor #19 6:12 APIC version 21 +(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 +(XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec80000, GSI 24-47 +(XEN) Enabling APIC mode: Phys. Using 2 I/O APICs +(XEN) Failed to get Error Log Address Range. +(XEN) Using scheduler: SMP Credit Scheduler (credit) +(XEN) Detected 2533.485 MHz processor. +(XEN) Initing memory sharing. +(XEN) Intel VT-d iommu 0 supported page sizes: 4kB. +(XEN) Intel VT-d Snoop Control not enabled. +(XEN) Intel VT-d Dom0 DMA Passthrough not enabled. +(XEN) Intel VT-d Queued Invalidation enabled. +(XEN) Intel VT-d Interrupt Remapping not enabled. +(XEN) Intel VT-d Shared EPT tables not enabled. +(XEN) I/O virtualisation enabled +(XEN) - Dom0 mode: Relaxed +(XEN) Interrupt remapping disabled +(XEN) Enabled directed EOI with ioapic_ack_old on! +(XEN) ENABLING IO-APIC IRQs +(XEN) -> Using old ACK method +(XEN) Platform timer is 14.318MHz HPET +(XEN) Allocated console ring of 32 KiB. +(XEN) VMX: Supported advanced features: +(XEN) - APIC MMIO access virtualisation +(XEN) - APIC TPR shadow +(XEN) - Extended Page Tables (EPT) +(XEN) - Virtual-Processor Identifiers (VPID) +(XEN) - Virtual NMI +(XEN) - MSR direct-access bitmap +(XEN) - Unrestricted Guest +(XEN) HVM: ASIDs enabled. +(XEN) HVM: VMX enabled +(XEN) HVM: Hardware Assisted Paging (HAP) detected +(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB +(XEN) Brought up 12 CPUs +(XEN) *** LOADING DOMAIN 0 *** +(XEN) Xen kernel: 64-bit, lsb, compat32 +(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f18000 +(XEN) PHYSICAL MEMORY ARRANGEMENT: +(XEN) Dom0 alloc.: 000000049c000000->00000004a0000000 (110661 pages to be allocated) +(XEN) Init. ramdisk: 00000004aee45000->00000004afdff7d5 +(XEN) VIRTUAL MEMORY ARRANGEMENT: +(XEN) Loaded kernel: ffffffff81000000->ffffffff81f18000 +(XEN) Init. ramdisk: ffffffff81f18000->ffffffff82ed27d5 +(XEN) Phys-Mach map: ffffffff82ed3000->ffffffff82fd3000 +(XEN) Start info: ffffffff82fd3000->ffffffff82fd34b4 +(XEN) Page tables: ffffffff82fd4000->ffffffff82ff1000 +(XEN) Boot stack: ffffffff82ff1000->ffffffff82ff2000 +(XEN) TOTAL: ffffffff80000000->ffffffff83400000 +(XEN) ENTRY ADDRESS: ffffffff819021f0 +(XEN) Dom0 has maximum 1 VCPUs +(XEN) Scrubbing Free RAM: .................................................................................................................................................................................done. +(XEN) Initial low memory virq threshold set at 0x4000 pages. +(XEN) Std. Loglevel: Errors and warnings +(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) +(XEN) Xen is relinquishing VGA console. +(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) +(XEN) Freed 284kB init memory. + +# perf report +# To display the perf.data header info, please use --header/--header-only options. +# +# Samples: 6K of event 'cpu-clock' +# Event count (approx.): 1744250000 +# +# Overhead Command Shared Object Symbol +# ........ ............... ....................... .................................... +# + 8.69% qemu-system-i38 [kernel.kallsyms] [k] xen_hypercall_xen_version + 2.29% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acac8 + 2.01% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acad9 + 1.53% qemu-system-i38 qemu-system-i386 [.] 0x00000000000ac978 + 1.33% qemu-system-i38 qemu-system-i386 [.] 0x00000000000ac989 + 1.02% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acaa4 + 0.93% qemu-system-i38 libc-2.19.so [.] memset + 0.70% qemu-system-i38 qemu-system-i386 [.] 0x00000000000e2814 + 0.69% qemu-system-i38 qemu-system-i386 [.] 0x00000000000e37f4 + 0.67% qemu-system-i38 qemu-system-i386 [.] 0x00000000000aca40 + 0.66% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acadf + 0.60% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acad7 + 0.59% qemu-system-i38 [vdso] [.] __vdso_clock_gettime + 0.59% qemu-system-i38 qemu-system-i386 [.] 0x0000000000342b88 + 0.57% qemu-system-i38 [vdso] [.] __vdso_gettimeofday + 0.52% qemu-system-i38 [kernel.kallsyms] [k] pvclock_clocksource_read + 0.49% qemu-system-i38 qemu-system-i386 [.] 0x00000000000a9e45 + 0.46% qemu-system-i38 [kernel.kallsyms] [k] do_sys_poll + 0.37% qemu-system-i38 [kernel.kallsyms] [k] hrtimer_init + 0.36% qemu-system-i38 [kernel.kallsyms] [k] __fget + 0.34% qemu-system-i38 [kernel.kallsyms] [k] ktime_get_ts \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1453612 b/results/classifier/accel-gemma3:12b/vmm/1453612 new file mode 100644 index 000000000..df7b87574 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1453612 @@ -0,0 +1,6 @@ + +set_password command of monitor has poor feedback on failure + +running `set_password vnc NkkmEz5icvTAGo6MECzBVEUxP` in qemu monitor started with `-monitor stdio` gives feedback `Could not set password` which is unhelpful because it doesn't specify the reason of the failure. + +experienced with 2.3.0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1453613 b/results/classifier/accel-gemma3:12b/vmm/1453613 new file mode 100644 index 000000000..527a81ace --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1453613 @@ -0,0 +1,4 @@ + +the help message of the set_password subcommand of the qemu monitor isn't usable + +`help set_password` in qemu monitor prints `set_password protocol password action-if-connected -- set spice/vnc password` which doesn't allow to figure out how to use this subcommand. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1459 b/results/classifier/accel-gemma3:12b/vmm/1459 new file mode 100644 index 000000000..092eaef1f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1459 @@ -0,0 +1,36 @@ + +analyze-migration.py doesn't account for saved blocks +Description of problem: + +Steps to reproduce: +1. Make a migration snapshot that includes incremental block device (from HMP: `migrate -i "exec: cat > snap"`) +2. Load the snapshot: `scripts/analyze-migration.py -f snap` + + +``` +Traceback (most recent call last): + File "scripts/analyze-migration.py", line 605, in <module> + dump.read(dump_memory = args.memory) + File "scripts/analyze-migration.py", line 539, in read + classdesc = self.section_classes[section_key] +KeyError: ('block', 0) +``` +Additional information: +Here's pseudocode derived from `block_load` in `migration/block.c`: + +``` +N blocks of the following: + + read 64 bits: sector number and flags + (blk->sector << BDRV_SECTOR_BITS) | flags + + if flags & BLK_MIG_FLAG_EOS: + break + if flags & BLK_MIG_FLAG_PROGRESS + continue + if flags & BLK_MIG_FLAG_DEVICE_BLOCK + byte: name length + length bytes: device name string + if not flags & BLK_MIG_FLAG_ZERO_BLOCK: + read (1 << 20) bytes +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/146 b/results/classifier/accel-gemma3:12b/vmm/146 new file mode 100644 index 000000000..822fd275d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/146 @@ -0,0 +1,2 @@ + +macOS Guest Reading USB 3.0 Bus as USB 2.0 diff --git a/results/classifier/accel-gemma3:12b/vmm/1463172 b/results/classifier/accel-gemma3:12b/vmm/1463172 new file mode 100644 index 000000000..e01ff04af --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1463172 @@ -0,0 +1,4 @@ + +destination arm board hangs after migration from x86 source + +The qemu destination on an arm board hangs after migration from a x86 source. With qemu emulating Arch, the migration works fine while the vm is still in the boot selection screen, but if the machine is booted, then the destination arm board vm hangs indefinitely after migrating from the x86 source. This bug does not occur the other way around, meaning a booted vm originally run on arm board will continue to work after migrating to a x86 destination. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1463463 b/results/classifier/accel-gemma3:12b/vmm/1463463 new file mode 100644 index 000000000..9b7536fd3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1463463 @@ -0,0 +1,13 @@ + +PCI devices on PCI to PCI bridges stopped being accessable from Xen with QEMU 2.3.0 + +The change set: + +commit 3996e85c1822e05c50250f8d2d1e57b6bea1229d +Author: Paul Durrant <email address hidden> +Date: Tue Jan 20 11:06:19 2015 +0000 + + Xen: Use the ioreq-server API when available +... + +Added calls to xen_map_pcidev() when available. However these call are only done at startup, not when the guest configures the PCI to PCI bridge. So Xen 4.5.0 (which has these) using a QEMU 2.3.0 or later can no longer access PCI devices that are not on a root bridge. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1474263 b/results/classifier/accel-gemma3:12b/vmm/1474263 new file mode 100644 index 000000000..865ed3dcd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1474263 @@ -0,0 +1,18 @@ + +"Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver + +Running + +qemu -drive file.driver=vvfat,file.dir=. + +displays + +WARNING: Image format was not specified for 'json:{"dir": ".", "driver": "vvfat"}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +However, since "images" provided by the vvfat driver are always raw (and the first sector isn't writeable in any case), this warning is superfluous and should not be displayed. + +A similar warning is displayed for NBD devices; I suspect it should be also disabled for similar reasons, but I'm not sure if serving non-raw images is actually a violation of the protocol. qemu-nbd translates them to raw images, for what it's worth, even if it may be suppressed with -f raw. + +Noticed on 2.3.0; the code that causes this behaviour is still apparently present in today's git master (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you may want to update the copyright notice that qemu -version displays. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1476800 b/results/classifier/accel-gemma3:12b/vmm/1476800 new file mode 100644 index 000000000..8c4a3e6ba --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1476800 @@ -0,0 +1,4 @@ + +Instant runtime error (Host: Windows 8.1 VM: WinXP ISO) + +I have Qemu Manager on my Windows 8.1 laptop and have a WXP iso and a blank disk image (from here http://www.mediafire.com/download/rtec86bwwmee00s/Blank_Disk.zip ) and as soon as I try to open it I get a Runtime Error ( http://i.gyazo.com/bfebf7e1e7a670f8e52cc95c5923a67e.png ) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1477538 b/results/classifier/accel-gemma3:12b/vmm/1477538 new file mode 100644 index 000000000..c51122a19 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1477538 @@ -0,0 +1,57 @@ + +Windows QEMU Guest Agent VSS Provider service stops during qemu backup + +I’m currently implementing the QEMU Guest Agent on all my KVM Windows guests. + +I’m using the stable VirtIO drivers and Guest agent from Fedora: https://fedoraproject.org/wiki/Windows_Virtio_Drivers + +Both the stable and latest release do provide Qemu Windows Guest agent 7.0.0.10. + +After the Guest agent installation I initially received VSS events with ID 8194: + + Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +This is often caused by incorrect security settings in either the writer or requestor process. +Operation: + Gathering Writer Data +Context: + + Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220} + + Writer Name: System Writer + + Writer Instance ID: {6c777a34-53dd-4fb3-a4c9-b85d7e183e27} + + +I was able to fix this issue by adding local access permissions for the “Network Service” account at the Dcom security permissions: + +On the client computer from the Start Menu, select Run +The Run dialog opens. +In the Open field type dcomcnfg and click OK. +The Component Services dialog opens. +Expand Component Services, Computers, and My Computer. +Right-click My Computer and click Properties on the pop-up menu. +The My Computer Properties dialog opens. +Click the COM Security tab. +Under Access Permission click Edit Default. +The Access Permissions dialog opens. +From the Access Permissions dialog, add the "Network Service" account with Local Access allowed. +Close all open dialogs. + +Now an initial backup runs without any errors but this is causing the QEMU Guest Agent VSS Provider service to stop running without any error in the event log. + +As a result a second backup will cause an error: MSDTC Client 2 with event ID: 4879: + +MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system SERVERNAME. + +This is probably caused because the QEMU Guest Agent VSS Provider service isn’t running anymore. + +I can manually start the QEMU Guest Agent VSS Provider service but every backup is causing the service to stop. + +I’m seeing this behavior at all my Windows based guests running both Windows Server 2012 R2 and Windows Server 2008 R2. + + Since I can’t find any logging or troubleshooting possibilities for this particular service I'm open for suggestions how to troubleshoot this issue to receive detailed information about the reason why this services stops running during a backup. + + +qemu-server 3.4-3 amd64 +Guest agent 7.0.0.10 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1479717 b/results/classifier/accel-gemma3:12b/vmm/1479717 new file mode 100644 index 000000000..f4c563d99 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1479717 @@ -0,0 +1,6 @@ + +Auto resize VM doesn't work with windows 10 guest + +I,m using a Ubuntu 15.04 host and a windows 10 guest (both 64 bit) on a intel i7 proc. My ubuntu system is up-to-date and I'm using QEMU emulator version 2.2.0. I use virt-manager 1.0.1 and SPICE guest tools 0.100 are installed on the guest. + +With the exactly same setup and a windows 7 guest I can set "Auto resize VM with window" and it perfectly works. After installing SPICE in windows 10 I can still select this box, but it doesn't work any longer. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/148 b/results/classifier/accel-gemma3:12b/vmm/148 new file mode 100644 index 000000000..8692bd2bb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/148 @@ -0,0 +1,2 @@ + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM diff --git a/results/classifier/accel-gemma3:12b/vmm/1484925 b/results/classifier/accel-gemma3:12b/vmm/1484925 new file mode 100644 index 000000000..80cbd4361 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1484925 @@ -0,0 +1,25 @@ + +Segfault with custom vnc client + +Hey, + +I'm using Citrix XenServer 6.5. I worte a script that uses noVNC to connect to the rfb console via xapi. When I use GRML and try to boot it, the QEMU process segfaults and kills my VM. This happens when the screen resizes and the kernel is loading: + +recvfrom(3, "\3\1\0\0\0\0\2\200\1\220\3\0\2\200\0\0\0P\1\220", 4096, 0, NULL, NULL) = 20 +--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb28000} --- + +I can see in the child process the following message, right before the parent Segfaults: +read(4, "cirrus: blanking the screen line_offset=0 height=480\n", 53) = 53 + +This issue only happens, when I have my custom php/novnc-client connected. I also tried the nodejs/novnc package from xen-orchestra - same result. Using the stock client from Citrix XenCenter it works just fine. So I think it is related to noVNC. I hope this is just a bug and not exploitable to force a VM to crash or execute code. + +XenServer launches the qemu with the following command line: + +qemu-dm-25 --syslog -d 25 -m 2048 -boot dc -serial pty -vcpus 1 -videoram 4 -vncunused -k en-us -vnc 127.0.0.1:1 -usb -usbdevice tablet -net nic,vlan=0,macaddr=8a:43:e2:b1:57:df,model=rtl8139 -net tap,vlan=0,bridge=xenbr0,ifname=tap25.0 -acpi -monitor pty + +XenServer 6.5 is using the following version: +# /usr/lib64/xen/bin/qemu-dm -help +QEMU PC emulator version 0.10.2, Copyright (c) 2003-2008 Fabrice Bellard + +Greetings +Uli Stärk \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1485010 b/results/classifier/accel-gemma3:12b/vmm/1485010 new file mode 100644 index 000000000..33dc70bb4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1485010 @@ -0,0 +1,6 @@ + +qemu-guest-agent should support systemd in addition to pmutils + +Hello, + +Shouldn't the qemu-guest-agent also support systemd function in addition to the existing call to pm-suspend, shutdown, hwclock. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1485180 b/results/classifier/accel-gemma3:12b/vmm/1485180 new file mode 100644 index 000000000..94d49de7b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1485180 @@ -0,0 +1,22 @@ + +Ctrl Alt G -- Multiple Virtual Machines + +I'm using Fedora 22. + +Firstly, what works: +A single VM instance, running Windows. Although, I am keeping this (GTK) window focused. + +What really fails: +If I have two running VM's, WIndows XP and Windows Vista: +1. I press Ctrl-Alt-G to get the focus. +2. That works first time. +3. Then I press Ctrl-Alt-G again. +4. Then Alt-Tab to the other machine (switching from XP to Vista, or back.) +5. Then press Ctrl-Alt-G to gain focus: +- Problem is that now the Ctrl-Alt-G, although showing in the title bar, only grabs the mouse, but NOT the keyboard. That is to say, whilst in Ctrl-Alt-G mode the second time, pressing Alt-Tab jumps back to the other VM! + +Pressing Alt-F4 quits!!!!!!!!!!!!! Regardless of whether Ctrl-Alt-G mode or not! +But only when running two VM's. + +Thanks +Misha \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1486278 b/results/classifier/accel-gemma3:12b/vmm/1486278 new file mode 100644 index 000000000..c0632d7ce --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1486278 @@ -0,0 +1,18 @@ + +'info vnc' monitor command does not show websocket information + +Steps to reproduce^ +1. run + qemu-system-x86_64 -vnc 0.0.0.0:1,websocket=5701 -nographic -monitor stdio + +2. then type + (qemu) info vnc +3. see + address: 0.0.0.0:5901 + auth: none +Client: none + +There is no information about websocket parameters, but 'netstat -nltp' shows me: + ... +tcp 0 0 0.0.0.0:5701 0.0.0.0:* LISTEN 27073/qemu-system-x +.... \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1486768 b/results/classifier/accel-gemma3:12b/vmm/1486768 new file mode 100644 index 000000000..892666378 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1486768 @@ -0,0 +1,18 @@ + +BlackMagic USB3 video capture returns only blank frames in Windows (xHCI issue) + +Hi, + +I've got an Intensity Shuttle USB3; it's a HDMI video capture card. It doesn't have any Linux drivers, so I'm trying to get it to work in a Windows 10 guest inside QEMU. I'm running latest git as of today (2015-08-20). I use this command line: + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -device nec-usb-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x1edb,productid=0xbd3b -usbdevice tablet + +(I will add that the seemingly logical “host:1edb:bd3b,bus=xhci.0” did _not_ add the device at all. I don't know why, probably some parser issue?) + +The card is properly detected, and the driver thinks everything is fine, running on the virtualized USB3 host and all. Looking at usbmon, there's lots of isochronous frames during capture, and they reach the host (looking at USBpcap on the Windows 10 side). However, the driver refuses to capture any video—all frames become black in all applications I try (well, Media Express seems to hardly store any frames at all in the .avi). However, audio is captured without a hitch. Curiously enough, no dropped frames are reported. There's no sign of CPU shortage; both host and guest seem to be happy around 20% of one core. + +I am fairly certain this is an issue with the xHCI driver in QEMU, because if I give it the entire USB controller via VT-d, it works flawlessly, with video and all. For reference, here's the associated command line I use for that (after I've unbound it from the Linux system): + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -usbdevice tablet -device pci-assign,host=00:14.0 + +I can get USB pcap logs from both sides if you want, but they are huge (gigabytes) since the data rate is so high. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1488363 b/results/classifier/accel-gemma3:12b/vmm/1488363 new file mode 100644 index 000000000..c62957e80 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1488363 @@ -0,0 +1,54 @@ + +qemu 2.4.0 hangs using vfio for pci passthrough of graphics card + +2.3.0 (manjaro distro package) works fine. 2.4.0 (manjaro or the arch vanilla one) hangs on the SeaBIOS screen when saying "Press F12 for boot menu". All tested with the same hardware, OS, command and configuration. It also starts without the GPU passed through, even with the USB passed through. I am using the latest SeaBIOS 1.8.2. + +The release notes say: + VFIO + Support for resetting AMD Bonaire and Hawaii GPUs + Platform device passthrough support for Calxeda xgmac devices + +So maybe something there broke it. + +I am using the arch qemu 2.4.0 PKGBUILD (modified to have make -j8 and removed iscsi, gluster, ceph, etc.), which uses vanilla sources and no patches. https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qemu + +I am not using a frontend. I am using a script I wrote that generates the command below. + +Guest OS here would be 64 bit windows 7, but it didn't start so that's not relevant. Also a Manjaro Linux VM won't start. + +CPU is AMD FX-8150; board is Gigabyte GA-990FXA-UD5 (990FX chipset). + +full command line (without the \ after each line) is: + +qemu-system-x86_64 + -enable-kvm + -M q35 + -m 3584 + -cpu host + -boot c + -smp 7,sockets=1,cores=7,threads=1 + -vga none + -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 + -device vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom + -device vfio-pci,host=00:14.2,bus=pcie.0 + -device vfio-pci,host=00:16.0,bus=root.1 + -device vfio-pci,host=00:16.2,bus=root.1 + -usb + -device ahci,bus=pcie.0,id=ahci + -drive file=/dev/data/vm1,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on + -drive media=cdrom,id=cdrom,index=5,media=cdrom + -netdev type=tap,id=net0,ifname=tap-vm1 + -device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05 + -monitor stdio + -boot menu=on + + +$ lspci -nn | grep -E "04:00.0|00:14.2|00:16.0|00:16.2" +00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) +00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] +00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] +04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X] [1002:6658] + + +Also I have this one that also hangs: +05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba] \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1490 b/results/classifier/accel-gemma3:12b/vmm/1490 new file mode 100644 index 000000000..a5f4493e2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1490 @@ -0,0 +1,62 @@ + +Keystrokes for F13-24 are not forwarded by an evdev input device +Description of problem: +Currently, keystrokes for F13-F24 are not forwarded by an evdev input device. +Steps to reproduce: +``` +/usr/bin/qemu-system-x86_64 \ +-name guest=win10,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-11-win10/master-key.aes"}' \ +-machine pc-q35-7.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \ +-m 4096 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=4,threads=1 \ +-uuid ca2e9d01-6e02-4aa7-9feb-7846499f7d8a \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.1","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/tmp/win10.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":2}' \ +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' \ +-audiodev '{"id":"audio1","driver":"spice"}' \ +-spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ +-device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.2","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +``` + +This is probably not a minimal example, but I didn't know how to generate one. I think the only relevant lines are these: +``` +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1493033 b/results/classifier/accel-gemma3:12b/vmm/1493033 new file mode 100644 index 000000000..2b2d0005f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1493033 @@ -0,0 +1,50 @@ + +memory leak/high memory usage with spice webdav feature + +This bug is being open due the comment: +https://bugs.freedesktop.org/show_bug.cgi?id=91350#c9 + +Description of problem: +When copying big files from client to guest, the memory usage in the host grows by about the size of the file. This is partially spice problem due the memory pool being able to increase as much as necessary without a limit which should be handled by the patches sent in the mailing list [0] + +[0] http://lists.freedesktop.org/archives/spice-devel/2015-August/021644.html + +At the same time, massif shows high memory usage by qemu as well [1] (output attached) + +[1] (peak) +->49.64% (267,580,319B) 0x308B89: malloc_and_trace (vl.c:2724) +| ->49.38% (266,167,561B) 0x67CE678: g_malloc (gmem.c:97) +| | ->49.03% (264,241,152B) 0x511D8E: qemu_coroutine_new (coroutine-ucontext.c:106) +| | | ->49.03% (264,241,152B) 0x510E24: qemu_coroutine_create (qemu-coroutine.c:74) +(...) + +The file being shared was a 320M ogv video. + +Version-Release number of selected component (if applicable): +QEMU emulator version 2.3.93 +SPICE and SPICE-GTK: from git master + +How reproducible: +100% + +Steps to Reproduce: +1-) build spice-gtk with --enable-webdav=yes +2-) enable webdav in your VM by following: +https://elmarco.fedorapeople.org/manual.html#_folder_sharing +3-) using remote-viewer with webdav patches, connects to a fedora guest +4-) Open nautilus, go to 'Browse Network' +5-) On remote-viewer, enable shared folder by File > Preferences > [X] Share folder +6-) The spice client folder should appear: Double-click to mount it. +7-) Check the memory of your qemu process +8-) Copy a big file (let's say, 300 MB) from the shared folder to local VM +9-) See the memory consumption of qemu grows by a lot; + +Actual results: +Memory usage grows during copy and is not freed + +Expected results: +Memory should have an upper limit to grow and should be freed after copy + +Additional info: +Also reported in Fedora/rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1256376 +SPICE upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=91350 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1499908 b/results/classifier/accel-gemma3:12b/vmm/1499908 new file mode 100644 index 000000000..4558c42b6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1499908 @@ -0,0 +1,56 @@ + +hda sound capture broken with VNC + +QEmu is being used to run the Wine conformance tests in Windows virtual machines. Wine's conformance tests check the behavior of various Windows APIs and verify that they behave as expected. One of the tests checks the behavior of the mmdevapi sound capture APIs. This test works fine on real hardware and also works fine in various QEmu VMs but fails in some others. Further investigation showed that: + + * The mmdevapi:capture tests work on the two Vista VMs. Those use the ac97 sound card and are configured for VNC access to the VM. + + * The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an hda sound card and are configured for VNC access to the VM (so '-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0'). + + * Furthermore configuring the VM for Spice access fixes the mmdevapi:capture test (so replacing -vnc with '-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'), this even if no client connects to the VM. + +So in effect the -spice and -vnc options change the behavior of the sound device. + +To reproduce this bug: +1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt). +2. Set it up for access using VNC. +3. Copy the attached mmdevapi_test.exe file to it. (*) +4. Run the tests as follows: + mmdevapi_test.exe capture + +If you see these 'Test Failed' lines then the bug is still present: + +capture.c:586: Returned latency: 5.8050 ms +capture.c:178: Test failed: Position 1015 expected 0 +capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked: 448 +capture.c:228: Test failed: Position 2167 expected 1463 +capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames locked: 448 +capture.c:256: Test failed: Position 2167 expected 1463 +capture.c:292: GetBufferSize 21996 period size 448 +capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames locked: 448 +capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996 +capture.c:313: Test failed: Position 4215 gap 2304 +capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames locked: 448 +capture.c:333: Test failed: Position 5303 expected 4663 +capture.c:334: Test failed: flags 1 +capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames locked: 448 +capture.c:358: Test failed: Position 7351 expected 5111 +capture.c:359: Test failed: flags 1 + +In case it helps, here is the source of mmdevapi_test.exe: +https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178 + + +So far I have confirmed that this bug is present in QEmu as shipped in the following Debian packages: + * qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 + linux-image-3.16.0-4-amd64 3.16.7-ckt11-1+deb8u3 + * qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1 + + +(*) As alternatives to using the attached binary you can: +- Compile it from Wine's source. See: + https://source.winehq.org/git/wine.git/ + +- Or download the latest WineTest binary from https://test.winehq.org/builds/winetest-latest.exe + And extract the mmdevapi_test.exe from there: + winetest.exe -x tests + tests\mmdevapi_test.exe capture \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1500265 b/results/classifier/accel-gemma3:12b/vmm/1500265 new file mode 100644 index 000000000..26339ab88 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1500265 @@ -0,0 +1,6 @@ + +nested 9p filesystem with security_model=mapped-xattr + +I do not know whether this is a bug or a feature request, but on a 9p virtfs with security_model=mapped-xattr, access to extended attributes starting with "user.virtfs" coming from the guest seem to be silently ignored. Would it not be more correct to use some sort of "escaping", say map to "user.virtfs.x" on guest to "user.virtfs.virtfs.x" on host or something like that, so that the guest can use arbitrary attributes. + +In particular, this would allow nested virtual machines to use nested 9p virtfs with security_model=mapped-xattr. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1502613 b/results/classifier/accel-gemma3:12b/vmm/1502613 new file mode 100644 index 000000000..a62956284 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1502613 @@ -0,0 +1,8 @@ + +[Feature Request] Battery Status / Virtual Battery + +When using virtualization on notebooks heavily then virtual machines do not realize that they're running on a notebook device causing high power consumption because they're not switching into a optimized "laptop mode". This leads to the circumstance that they are trying to do things like defragmentation / virtus scan / etc. while the host is still running on batteries. + +So it would be great if QEMU / KVM would have support for emulating "Virtual Batteries" to guests causing them to enable power-saving options like disabling specific services / devices / file operations automatically by OS. + +Optionally a great feature would be to set virtual battery's status manually. For example: Current charge rate / charging / discharging / ... \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1502884 b/results/classifier/accel-gemma3:12b/vmm/1502884 new file mode 100644 index 000000000..0c43728a8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1502884 @@ -0,0 +1,15 @@ + +Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option! + +Hi, + +A big issue when using QEMU's VNC server (VNC KVM) is that, when there's a network lag, unintended keypresses go through to the QEMU guest VM. + +This is frequently "enter" keypresses, causing all kinds of unintended consequences in the VM. So basically it's extremely dangerous. + +This is because the VNC protocol's keyboard interaction is implemented in terms of key down - key up events, making the server's keyboard autorepeat kick in when it should not. + + +For this reason, it would be great if QEMU's VNC server part would be enhanced with an option such that when a VNC protocol key down is received, then locally that is treated as one single keypress only (I don't know how that should be implemented but I guess either as an immediate key down - key up sequence locally, or key down + key up after say 0.05 seconds), instead of waiting for the key up event from the VNC client. + +Thanks! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1504513 b/results/classifier/accel-gemma3:12b/vmm/1504513 new file mode 100644 index 000000000..cb0ec2072 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1504513 @@ -0,0 +1,26 @@ + +Socket leak on each call to qemu_socket() + +On any host platform where SOCK_CLOEXEC is defined (Linux at least), a socket is leaked on each call to qemu_socket() AND the socket returned hasn't been created with the desired SOCK_CLOEXEC attribute. The qemu_socket routine is: + +Line 272 of util/osdep.c: +/* + * Opens a socket with FD_CLOEXEC set + */ +int qemu_socket(int domain, int type, int protocol) +{ + int ret; + +#ifdef SOCK_CLOEXEC + ret = socket(domain, type | SOCK_CLOEXEC, protocol); + if (ret != -1 || errno != EINVAL) { + return ret; + } +#endif + ret = socket(domain, type, protocol); + if (ret >= 0) { + qemu_set_cloexec(ret); + } + + return ret; +} \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1504528 b/results/classifier/accel-gemma3:12b/vmm/1504528 new file mode 100644 index 000000000..599534c83 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1504528 @@ -0,0 +1,10 @@ + +qemu shows glib-warning with the new glib2 2.46 + +qemu shows the following warning with glib2 2.46.0: + +[tom@localhost ~]$ qemu-system-x86_64 + +(process:4222): GLib-WARNING **: gmem.c:482: custom memory allocation vtable not supported + +fwiw process 4222 is qemu-system-x86_64 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1505759 b/results/classifier/accel-gemma3:12b/vmm/1505759 new file mode 100644 index 000000000..6d0fb0d38 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1505759 @@ -0,0 +1,55 @@ + +Usb passthrough of devices plugged to AMD FCH USB OHCI Controller failing on q35. + +I'm trying to setup a q35 vm with windows 7 guest for vga passthrough. The machine works well for this purpose, but the usb devices passed to the vm does not. I receive the following errors on screen: + +qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] +libusb: error [_open_sysfs_attr} open +/sys/bus/usb/devices/3-5/bConfigurationValue failed ret=-1 errno=2 +qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] +libusb: error [_open_sysfs_attr} open +/sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2 +Disabling IRQ #18 +Disabling IRQ #17 + +And from the system log I can see the following: + +Oct 13 20:13:25 koalita kernel: vfio-pci 0000:01:00.1: enabling device (0400 -> 0402) +Oct 13 20:13:29 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:30 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:30 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:31 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:31 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:31 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:31 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:32 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:32 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:32 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:33 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:33 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:34 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:34 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes + +I tried to any combination of usb devices, and even disabling the ICH9 usb devices to make the setup looks close to the 440fx machine that is working for me. + +Version of qemu is 2.2.1(all newer versions fails on usb passthrough, even in 440fx machines), and kernel is 4.1.8. + +The script to launch it is the following: + +qemu-system-x86_64 -enable-kvm -M q35 -vga none -cpu host -smp 3,cores=3,threads=1 -m 6144 \ + -L /usr/x86_64-pc-linux-gnu/usr/share/qemu \ + -nodefaults -nodefconfig \ + -device ioh3420,multifunction=on,id=pcie \ + -device vfio-pci,host=01:00.0,addr=1c.0,x-vga=on,multifunction=on,bus=pcie \ + -device vfio-pci,host=01:00.1,addr=1c.1,bus=pcie \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -device usb-ehci,id=ehci -device nec-usb-xhci,id=xhci \ + -usb -usbdevice host:03f0:134a -usbdevice host:03f0:0024 -usbdevice host:0079:0006 \ + -drive file=q35_win7.img,format=raw,cache=none,aio=native,if=virtio + +Thanks! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1507 b/results/classifier/accel-gemma3:12b/vmm/1507 new file mode 100644 index 000000000..e72333d8d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1507 @@ -0,0 +1,38 @@ + +export/fuse/fuse.c:fuse_fallocate does not do anything but returns success +Description of problem: +block/export/fuse.c:fuse_fallocate with `FALLOC_FL_PUNCH_HOLE` does not do anything even though it returns 0 (success). A later read incorrectly returns old data instead of zeros. +Should probably return EOPNOTSUPP. + +FALLOC_FL_PUNCH_HOLE: +>Within the specified range, partial filesystem blocks are zeroed, +and whole filesystem blocks are removed from the file. After a +successful call, subsequent reads from this range will return +zeros. +https://man7.org/linux/man-pages/man2/fallocate.2.html +Steps to reproduce: +```sh +touch /tmp/data /tmp/fuse_exp +dd if=/dev/random of=/tmp/data count=1000 bs=1M +qemu-storage-daemon --blockdev node-name=node0,driver=raw,file.driver=file,file.filename=/tmp/data --export type=fuse,id=node0-export,node-name=node0,mountpoint=/tmp/fuse_exp,writable=on + +hexdump /tmp/fuse_exp -n 16 +# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86 +fallocate -l 1G --punch-hole /tmp/fuse_exp +echo $? +# 0 +hexdump /tmp/fuse_exp -n 16 +# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86 + + +hexdump /tmp/data -n 16 +# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86 +fallocate -l 1G --punch-hole /tmp/data +hexdump /tmp/data -n 16 +# 0000000 0000 0000 0000 0000 0000 0000 0000 0000 + +# sudo bpftrace -e 'uretprobe:/usr/bin/qemu-storage-daemon:blk_co_pdiscard { printf("ret=%d\n",retval); }' +# ret=0 +# sudo bpftrace -e 'kretfunc:fuse_file_fallocate { printf("len=%d \t mode=%d ret=%d\n", args->length , args->mode,retval); }' +# len=1073741824 mode=3 ret=0 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1513234 b/results/classifier/accel-gemma3:12b/vmm/1513234 new file mode 100644 index 000000000..7b88deb5f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1513234 @@ -0,0 +1,12 @@ + +Cannot ping guest from host after closing laptop lid, and re-opening + +I am running Ubuntu 15.10 (this issue also exists on 15.04) x64. Desktop environment to re-produce is either GNOME 3.16 or OpenBox-3. + +I have a Windows 8.1 VM that I run with QEMU and I will work out of that for my job most of the day. When I am going to leave I like to just close my laptop lid, come home, and then get back at it. Unfortunately whenever I get home and open back up my laptop, I can no longer RDP into my VM and can no longer ping it from the host. + +If I open up Virt-Manager I can see the desktop via the Console page but cannot RDP into it with FreeRDP (I use FreeRDP all day on this machine so I know this works fine). + +If I use the Console tab to login to the Windows VM again, I notice that I can ping the host from the guest and am connected to the internet. Just can't seem to communicate with the VM via its IP anymore. + +I have a NIC NAT virtual card and am using a Bridge \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1515 b/results/classifier/accel-gemma3:12b/vmm/1515 new file mode 100644 index 000000000..177ef5fbb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1515 @@ -0,0 +1,19 @@ + +qemu have the way to change the windows sid? +Description of problem: +I want to change the guest of windows sid after clone guest, have the way to change it before new guest start? "virt-sysprep" Seems impossible to do it. Although it can be done manually as follow: + +[change sid in windows system](https://www.heelpbook.net/2019/microsoft-changing-sid-of-cloned-vms/) + +query windows sid: +cmd: whoami /user + + +step: +1.clone a new windows guest vm_new + +2.change the sid of vm_new (step2 I don't know how to do that) + +3.start vm_new + +4.query the vm_new's sid is change diff --git a/results/classifier/accel-gemma3:12b/vmm/1516446 b/results/classifier/accel-gemma3:12b/vmm/1516446 new file mode 100644 index 000000000..42a72381e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1516446 @@ -0,0 +1,531 @@ + +Migration always causes guest freeze in one direction. + +Hello, + +I have three debian jessie machines standard installations except for homebuild qemu-2.4.0 package using the source package from testing. I had the same problem with the standard debian jessie qemu 2.1 too. + +I have host A, B and C. + +Migrations work between all combinations of these except A -> B. B -> A works. + +I use libvirt but as per your written request I have run qemu directly and verified the same problem. + +Host A: +qemu-system-x86_64 --enable-kvm -name ashole -cpu kvm64 -m 1024 -drive file=/mnt/synctest/ashole.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none -vnc 0.0.0.0:600 -k sv -vga std -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 + +Host B: +qemu-system-x86_64 --enable-kvm -name ashole -cpu kvm64 -m 1024 -drive file=/mnt/synctest/ashole.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none -vnc 0.0.0.0:600 -k sv -vga std -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -incoming tcp:0:4444 + +Then in qemu monitor I run migrate -d tcp:B:4444 and the guest freeze. + +I have tried with these guest os:es, freebsd 9.1, debian wheezy and debian jessie (Standard 3.16 kernel and backported 4.2 kernel), same problem with all of them. when running the migration through libvirt virt-manager says the guest is using 100% cpu. + +I had a similar problem (https://bugzilla.kernel.org/show_bug.cgi?id=61971) 2 years ago which was solved in kernel 3.13 if I remember correctly. + +Best Regards +Magnus + +CPU info: +Host A +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 0 +cpu cores : 4 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 1 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 1 +cpu cores : 4 +apicid : 17 +initial apicid : 1 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 2 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1700.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 2 +cpu cores : 4 +apicid : 18 +initial apicid : 2 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 3 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 3 +cpu cores : 4 +apicid : 19 +initial apicid : 3 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 4 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 4 +cpu cores : 4 +apicid : 20 +initial apicid : 4 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 5 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 5 +cpu cores : 4 +apicid : 21 +initial apicid : 5 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 6 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 6 +cpu cores : 4 +apicid : 22 +initial apicid : 6 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +processor : 7 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-8320 Eight-Core Processor +stepping : 0 +microcode : 0x600081f +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 7 +cpu cores : 4 +apicid : 23 +initial apicid : 7 +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 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 arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 +bugs : fxsave_leak sysret_ss_attrs +bogomips : 7023.54 +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 + +Host B: +processor : 0 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 6 +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 1 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 1 +cpu cores : 6 +apicid : 1 +initial apicid : 1 +fpu : yes +fpu_exception : yes +cpuid level : 6 +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 2 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 2 +cpu cores : 6 +apicid : 2 +initial apicid : 2 +fpu : yes +fpu_exception : yes +cpuid level : 6 +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 3 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 3 +cpu cores : 6 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 6 +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 4 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 4 +cpu cores : 6 +apicid : 4 +initial apicid : 4 +fpu : yes +fpu_exception : yes +cpuid level : 6 +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +processor : 5 +vendor_id : AuthenticAMD +cpu family : 16 +model : 10 +model name : AMD Phenom(tm) II X6 1055T Processor +stepping : 0 +microcode : 0x10000bf +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 6 +core id : 5 +cpu cores : 6 +apicid : 5 +initial apicid : 5 +fpu : yes +fpu_exception : yes +cpuid level : 6 +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall +bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs +bogomips : 5624.68 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate cpb + +Host C: +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1607.156 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 1 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1730.066 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 4 +apicid : 2 +initial apicid : 2 +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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 2 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1654.382 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 4 +apicid : 4 +initial apicid : 4 +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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 3 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz +stepping : 9 +microcode : 0x12 +cpu MHz : 1610.304 +cache size : 6144 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 6 +initial apicid : 6 +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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt +bugs : +bogomips : 6186.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1520730 b/results/classifier/accel-gemma3:12b/vmm/1520730 new file mode 100644 index 000000000..6bde01653 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1520730 @@ -0,0 +1,12 @@ + +32-bit editors vim/rhide broken keyboard handling in freedos 1.1 and ms-dos 6.22 + +This bug is present as of the latest commit: 714487515dbe0c65d5904251e796cd3a5b3579fb + +I also saw it in 2.4.1, but that was a distro package. + +You can see the bug simply using the following line: qemu-system-i386 -hda freedos.disk + +Simply type vim (or rhide) and start entering in some text. You'll notice repeating characters, and also eventually the key mode will change as if you're holding down the shift button. Not capslock. "a" will become "A", but "\" will also become "|". + +I don't think this is a bug in freedos because I get the same behavior with dos 6.22. Not dosbox, though. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1521 b/results/classifier/accel-gemma3:12b/vmm/1521 new file mode 100644 index 000000000..bb83f38e5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1521 @@ -0,0 +1,2 @@ + +USB HID not using the keycodemapdb and thus lacking new entries diff --git a/results/classifier/accel-gemma3:12b/vmm/1528718 b/results/classifier/accel-gemma3:12b/vmm/1528718 new file mode 100644 index 000000000..d94d96804 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1528718 @@ -0,0 +1,16 @@ + +Initial monitor does not output anything on Windows (MSYS2 binary) + +When running on Windows error messages before the UI is started are not showing up. + +For example when I run: + +qemu-system-i386.exe -L /mingw32/etc/qemu/ -m 20G + +It should display "ram size too large", according to gdb: + +Breakpoint 1, error_report (fmt=fmt@entry=0x71bdf6 <dma_aiocb_info+2426> "ram size too large") at C:/build/mingw/mingw-w64-qemu/src/qemu-2.4.0/util/qemu-error.c:233 + +However the console does never receive that. + +As far as I could find out vfprintf is called, but it doesn't output anything. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1529 b/results/classifier/accel-gemma3:12b/vmm/1529 new file mode 100644 index 000000000..9ee1563db --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1529 @@ -0,0 +1,2 @@ + +Documentation refers to Windows Hypervisor Platform as wphx instead of whpx diff --git a/results/classifier/accel-gemma3:12b/vmm/1529226 b/results/classifier/accel-gemma3:12b/vmm/1529226 new file mode 100644 index 000000000..aec8a1a99 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1529226 @@ -0,0 +1,12 @@ + +qemu-i386-user on 32-bit Linux: uncaught target signal 11 + +Even though the command I'm trying to run (a wrapper script for qemu-i386-user running rustc, the rust compiler) produces the expected compiled output, the build process is interrupted: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +i686-unknown-linux-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" +make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.rustc_back] Error 139 + +The stamp file is not being created so this could be about forking bash after finishing the wrapper script. + +Qemu was compiled from the latest git source. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1529764 b/results/classifier/accel-gemma3:12b/vmm/1529764 new file mode 100644 index 000000000..567224144 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1529764 @@ -0,0 +1,10 @@ + +No video output with the official Windows XP VMWare VGA driver + +Steps to reproduce: + +1) Set -vga to vmware +2) Install Windows XP SP3 +3) Install VGA drivers from http://packages.vmware.com/tools/releases/latest/windows/x86/VMware-tools-windows-10.0.5-3227872.iso + +Result: completely black screen (even after F8 -> use VGA mode). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1531632 b/results/classifier/accel-gemma3:12b/vmm/1531632 new file mode 100644 index 000000000..87a9a81b9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1531632 @@ -0,0 +1,95 @@ + +Can't compile qemu because of errors in the Xen code + +I'm using Arch Linux, with all needed libs packages installed via ABS (compiled from source). +I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all I had the same problems: + +First I have to disable -Werror, because it claims about some uninitialized variables. + +Trying to compile the code, it stops when compiling the xen code (hw/block/xendisk.o), complaining that ioservid_t is declared twice, first as 16bit and then as 32bit. + +Output of make: + + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1534978 b/results/classifier/accel-gemma3:12b/vmm/1534978 new file mode 100644 index 000000000..b577cb590 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1534978 @@ -0,0 +1,9 @@ + +Windows command line -name cannot use = sign + +Windows command line: + +qemu.exe -L . -name "32-bit Emulation Session RAM=500MB" -boot c -m 500 -drive file=\\.\PhysicalDrive2 + +This fails to run. +If I remove the = sign in the -name quoted string it runs OK. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1538541 b/results/classifier/accel-gemma3:12b/vmm/1538541 new file mode 100644 index 000000000..b90d47136 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1538541 @@ -0,0 +1,26 @@ + +qcow2 rejects request to use preallocation with backing file + +The 'preallocation=full' option to qemu-img / qcow2 block driver instructs QEMU to fully allocate the host file to the maximum size needed by the logical disk size. + +$ qemu-img create -f qcow2 -o preallocation=full base.qcow2 200M +Formatting 'base.qcow2', fmt=qcow2 size=209715200 encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 + +$ ls -alhs base.qcow2 +201M -rw-r--r--. 1 berrange berrange 201M Jan 27 12:49 base.qcow2 + + +When specifying a backing file for the qcow2 file, however, it rejects the preallocation request + +$ qemu-img create -f qcow2 -o preallocation=full,backing_file=base.qcow2 front.qcow2 200M +Formatting 'front.qcow2', fmt=qcow2 size=209715200 backing_file='base.qcow2' encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 +qemu-img: front.qcow2: Backing file and preallocation cannot be used at the same time + + +It might seem like requesting full preallocation is redundant because most data associated with the image will be present in the backing file, as so the top layer is unlikely to ever need the full preallocation. Rejecting this, however, means it is not (officially) possible to reserve disk space for the top layer to guarantee that future copy-on-writes will never get ENOSPC. + +OpenStack in particular uses backing files with all images, in order to avoid the I/O overhead of copying the backing file contents into the per-VM disk image. It, however, still wants to have a guarantee that the per-VM image will never hit an ENOSPC scenario. + +Currently it has to hack around QEMU's refusal to allow backing_file + preallocation, by calling 'fallocate' on the qcow2 file after it has been created. This is an inexact fix though, because it doesn't take account of fact that qcow2 metadata can takes some MBs of space. + +Thus, it would like to see preallocation=full supported in combination with backing files. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1541643 b/results/classifier/accel-gemma3:12b/vmm/1541643 new file mode 100644 index 000000000..5ebd1bda6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1541643 @@ -0,0 +1,8 @@ + +IA32_FEATURE_CONTROL MSR unset for nested virtualization + +I enabled nested virtualization for the kvm_intel module, and passed -enable-kvm and -cpu host to qemu. However, the qemu BIOS did not set IA32_FEATURE_CONTROL MSR (index 0x3a) to a non-zero value allow VMXON. According to the Intel manual Section 23.7 ENABLING AND ENTERING VMX OPERATION: "To enable VMX support in a platform, BIOS must set bit 1, bit 2, or both (see below), as well as the lock bit." + +I noticed an old mailing list thread on this (https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01372.html), but I wanted to point out that the Intel manual (and all the physical hardware I've tested) specifically contradicts this response. + +Tested on kernel 4.3.3 and qemu 2.4.1. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1545052 b/results/classifier/accel-gemma3:12b/vmm/1545052 new file mode 100644 index 000000000..1ac4af440 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1545052 @@ -0,0 +1,59 @@ + +RDMA migration will hang forever if target QEMU fails to load vmstate + +Get a pair of machines with infiniband support. On one host run + +$ qemu-system-x86_64 -monitor stdio -incoming rdma:ibme:4444 -vnc :1 -m 1000 + +To start an incoming migration. + + +Now on the other host, run QEMU with an intentionally different configuration (ie different RAM size) + +$ qemu-system-x86_64 -monitor stdio -vnc :1 -m 2000 + +Now trigger a migration on this source host + +(qemu) migrate rdma:ibpair:4444 + + +You will see on the target host, that it failed to load migration: + +dest_init RDMA Device opened: kernel name mlx4_0 uverbs device name uverbs0, infiniband_verbs class device path /sys/class/infiniband_verbs/uverbs0, infiniband class device path /sys/class/infiniband/mlx4_0, transport: (2) Ethernet +qemu-system-x86_64: Length mismatch: pc.ram: 0x7d000000 in != 0x3e800000: Invalid argument +qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' + +This is to be expected, however, at this point QEMU has hung and no longer responds to the monitor + +GDB shows the target host is stuck in this callpath + +#0 0x00007ffff39141cd in write () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff27fe795 in rdma_get_cm_event.part.15 () from /lib64/librdmacm.so.1 +#2 0x000055555593e445 in qemu_rdma_cleanup (rdma=0x7fff9647e010) at migration/rdma.c:2210 +#3 0x000055555593ea45 in qemu_rdma_close (opaque=0x555557796770) at migration/rdma.c:2652 +#4 0x00005555559397cc in qemu_fclose (f=f@entry=0x5555564b1450) at migration/qemu-file.c:270 +#5 0x0000555555936b88 in process_incoming_migration_co (opaque=0x5555564b1450) at migration/migration.c:361 +#6 0x0000555555a25a1a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:79 +#7 0x00007fffef5b3110 in ?? () from /lib64/libc.so.6 + + + +Now, back on the source host again, you would expect to see that the migrate command failed. Instead, this QEMU is hung too. + +GDB shows the source host, migrate thread, is stuck in this callpath: + +#0 0x00007ffff391522d in read#1 0x00007ffff00efd93 in ibv_get_cq_event () at /lib64/libibverbs.so.1 +#2 0x00005555559403f2 in qemu_rdma_block_for_wrid (rdma=rdma@entry=0x7fff3d07e010, wrid_requested=wrid_requested@entry=4000, byte_len=byte_len@entry=0x7fff39de370c) at migration/rdma.c:1511 +#3 0x000055555594058a in qemu_rdma_exchange_get_response (rdma=0x7fff3d07e010, head=head@entry=0x7fff39de3780, expecting=expecting@entry=2, idx=idx@entry=0) + at migration/rdma.c:1648 +#4 0x0000555555941e71 in qemu_rdma_exchange_send (rdma=0x7fff3d07e010, head=0x7fff39de3840, data=0x0, resp=0x7fff39de3870, resp_idx=0x7fff39de3880, callback=0x0) at migration/rdma.c:1725 +#5 0x00005555559447e4 in qemu_rdma_registration_stop (f=<optimized out>, opaque=<optimized out>, flags=0, data=<optimized out>) at migration/rdma.c:3302 +#6 0x000055555593bc4b in ram_control_after_iterate (f=f@entry=0x5555564c20f0, flags=flags@entry=0) at migration/qemu-file.c:157 +#7 0x0000555555740b59 in ram_save_setup (f=0x5555564c20f0, opaque=<optimized out>) at /home/berrange/src/virt/qemu/migration/ram.c:1959 +#8 0x00005555557451c1 in qemu_savevm_state_begin (f=0x5555564c20f0, params=params@entry=0x555555f6f048 <current_migration.37991+72>) + at /home/berrange/src/virt/qemu/migration/savevm.c:919 +#9 0x00005555559381a5 in migration_thread (opaque=0x555555f6f000 <current_migration.37991>) at migration/migration.c:1633 +#10 0x00007ffff390edc5 in start_thread (arg=0x7fff39de4700) at pthread_create.c:308 + + +It should have aborted migrate and set the status to failed. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1547012 b/results/classifier/accel-gemma3:12b/vmm/1547012 new file mode 100644 index 000000000..d405d79c2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1547012 @@ -0,0 +1,34 @@ + +qemu instances crashes with certain spice clients + +It's possible to make qemu instances crash when using certain browsers connected as spice-clients. + +my environment: + +- OpenStack Kilo installed from ubuntu-cloud archive (qemu-system-x86 2.2+dfsg-5expubuntu9.6~cloud0) +- Using spice for web-console access + +How to reproduce: + +1. Start a VM on openstack +2. access the OpenStack dashboard using iceweasel 43.0.4 +3. Open the spice-console +4. Leave the console open for few minutes +5. The VM will crash on the hypervisor + +The content of qemu log-files for this particular VM: + +2016-02-18 07:25:23.655+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name instance-0000188f -S -machine pc-i440fx-utopic,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid cb04ff25-056f-4f82-a2e8-1fbb762bc29e -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2015.1.2,serial=00000000-0000-0000-0000-0cc47a45f5e8,uuid=cb04ff25-056f-4f82-a2e8-1fbb762bc29e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000188f.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=rbd:libvirt/cb04ff25-056f-4f82-a2e8-1fbb762bc29e_disk:id=cinder:key=AQBYmdBUCDq7IBAA/7tLevRjdF3Bo7522xkFqA==:auth_supported=cephx\;none:mon_host=xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=55,id=hostnet0,vhost=on,vhostfd=58 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:a4:74:3b,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/cb04ff25-056f-4f82-a2e8-1fbb762bc29e/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -chardev pty,id=charchannel0 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5929,addr=172.24.1.30,disable-ticketing,seamless-migration=on -k fr-ch -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +char device redirected to /dev/pts/64 (label charserial1) +char device redirected to /dev/pts/65 (label charchannel0) +main_channel_link: add main channel client +main_channel_handle_parsed: net test: latency 44.136000 ms, bitrate 157538461538 bps (150240.384615 Mbps) +inputs_connect: inputs channel client create +red_dispatcher_set_cursor_peer: +((null):18188): SpiceWorker-CRITICAL **: red_worker.c:1629:common_alloc_recv_buf: unexpected message size 214862 (max is 1024) +2016-02-18 07:30:47.008+0000: shutting down + +It's funny because this error only occurs with certain browser versions, in my case with Iceweasel 43.0.4 and 44. 0 but it works well with Chrome 48.0.256482 and Firefox 44.0.2. + +Marking this a potential security issue as it could maybe lead to a denial-of-service if a user sends crafted packets. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1548 b/results/classifier/accel-gemma3:12b/vmm/1548 new file mode 100644 index 000000000..1718db82a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1548 @@ -0,0 +1,39 @@ + +8.0.0rc0 Regression: vnc fails with Segmentation fault +Description of problem: +On connecting with `gvncviewer localhost:05` the qemu process fails with +``` +Segmentation fault +``` +`gvncviewer localhost:05` prints +``` +Connected to server +Error: Server closed the connection +Disconnected from server +``` +Steps to reproduce: +1. Enter `qemu-system-x86_64 -m 1536 -display vnc=:05 -k de -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first terminal +2. Enter `gvncviewer localhost:05` in second terminal +Additional information: +Final output of `git bisect`: +``` +385ac97f8fad0e6980c5dfea71132d5ecfb16608 is the first bad commit +commit 385ac97f8fad0e6980c5dfea71132d5ecfb16608 +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Tue Jan 17 15:24:40 2023 +0400 + + ui: keep current cursor with QemuConsole + + Keeping the current cursor around is useful, not only for VNC, but for + other displays. Let's move it down, see the following patches for other + usages. + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> + + include/ui/console.h | 1 + + ui/console.c | 8 ++++++++ + ui/vnc.c | 7 ++----- + ui/vnc.h | 1 - + 4 files changed, 11 insertions(+), 6 deletions(-) +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1548471 b/results/classifier/accel-gemma3:12b/vmm/1548471 new file mode 100644 index 000000000..619c0662c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1548471 @@ -0,0 +1,10 @@ + +Lost of log file during block migration + + Hello, i've discovered that during live block migration +log file is copied(or created on destination) but it actually empty. +When regular(cold) migration is called log file migrates successfully. +I'm working on nova project in openstack and i've tried to fix it by adding +simple scp from source to destination, but log file is owned by libvirt-qemu user +and i cannot do that from regular user created by openstack. +Could explain how can i migrate logs safely? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1555452 b/results/classifier/accel-gemma3:12b/vmm/1555452 new file mode 100644 index 000000000..f51604085 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1555452 @@ -0,0 +1,10 @@ + +GDB server does not work in Windows + +I build qemu with msys2, MINGW64. After fix the socket_error() problem, and manually specify to use IPv4, GDB server still does not work. The related qemu command is +"-monitor none -nographic -gdb tcp::1234 -S" +GDB reports "Timed out" + +There's a message at https://<email address hidden>/msg357981.html. +I've fixed the socket_error() problem. +I see that qio_channel_create_socket_watch is called. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1556306 b/results/classifier/accel-gemma3:12b/vmm/1556306 new file mode 100644 index 000000000..71c5f1306 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1556306 @@ -0,0 +1,25 @@ + + vhost-user: qemu stops processing packets under high load of traffic + +Description of problem: +- qemu socket becomes full, causing qemu to send incomplete +SET_VRING_CALL messages to vhost-user backend (without proper fd set in +ancillary data). +- after some time, some interrupts are lost, causing the VM to stop +transmitting packets. + +How reproducible: +Run a stress tests of a vhost-user interface using an UDP +traffic generator. Traffic generator (IXIA) was connected to 2 physical ports that are in turn connected to 2 virtio ports through a linux bridge, VM +(running linux) doing routing to forward packets between the 2 virtio ports. +When traffic reaches high pps rates of small packets, + +Actual results: +- VM stop transmitting packets + +Expected results: +- VM should never stop transmitting packets + +Additional info: +We do propose a fix at: + http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00652.html \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1556372 b/results/classifier/accel-gemma3:12b/vmm/1556372 new file mode 100644 index 000000000..be67f982d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1556372 @@ -0,0 +1,11 @@ + +Superfluous popup on Cocoa to verify quit, cannot be disabled. + +This patch severely reduces the quality of life for developers using QEMU in a rapid Edit-Compile-Test cycle. +Any method of quitting QEMU via the UI triggers this dialogue, whose default option is "cancel" -- necessitating the use of the mouse to click "Confirm". + +This dialogue cannot be disabled by any flag, and is highly annoying. Recommend a flag to disable this confirmation, or in fact disable it by default and enable it with a flag. + +Patch in question: + +https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1558 b/results/classifier/accel-gemma3:12b/vmm/1558 new file mode 100644 index 000000000..1c1448dda --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1558 @@ -0,0 +1,22 @@ + +Bug checklist for AEHD +Description of problem: +There was a discussion on qemu-devel about addition of a new hypervisor, which is essentially a rewrite of linux/kvm, but for windows +- 202303002 Haito Shan [PATCH 0/6] Adding the Android Emulator hypervisor driver accelerator + https://lore.kernel.org/qemu-devel/CAGD3tSzW1QoAsn+uGjoAkBegLt1iZ=9YWDFcvqbcHMr0S_5kVw@mail.gmail.com/ + +If the new hypervisor AEHD does not support these, then each of the below may automatically qualify as a feature catchup bug +1) Nested Virtualization +2) virtio-GPU/virgl/OpenGL/venus +3) Vulkan passthrough +4) Xen emulation on KVM ( a feature also currently under development) + 20230302 [phase1-qemu-8.0](https://lore.kernel.org/qemu-devel/20230302123029.153265-1-pbonzini@redhat.com/) [PULL 00/62] i386, misc changes for QEMU 8.0 soft freeze + 20230307 [phase2-qemu-8.0](https://lore.kernel.org/qemu-devel/20230307171750.2293175-1-dwmw2@infradead.org/) [PATCH v2 00/27] Enable PV backends with Xen/KVM emulation +5) Migration +6) others?? + +perhaps also document if known for certain that there is no intention to catchup to a particular feature. +Steps to reproduce: +NA +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1558175 b/results/classifier/accel-gemma3:12b/vmm/1558175 new file mode 100644 index 000000000..0f0aa5a01 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1558175 @@ -0,0 +1,416 @@ + +virtio: vm killed (Guest moved used index) + +Hello, + +I ran a DPDK application with virtio ports. If I killed and relaunched it, VM is +killed by qemu with the following message: +> qemu-system-x86_64: Guest moved used index from 571 to 0 + +If I ran the same application with e1000 ports, I haven't this issue. + +Network topology +================ + +I used two VM machines with last qemu-2.5 with two virtio-net netdevs. Both +netdevs are connected through a VDE switch. + +On testnode, I used a Debian 8 (3.16) and virtio-net linux drivers. On DUT, I +used a Ubuntu 14.04 (3.13) with DPDK (next/16_04) with virtio pmd. + ++-------------------------------------------------------------+ +| | +| +-------------+ +-------------------+ | +| | | | | | +| | Testnode | | DUT | | +| | Debian 8 | | Ubuntu 14.04 | | +| | | +----------+ | | | +| | eth0 +----+ VDE +----+ eth0 pmd_virtio | | +| | virtio | +----------+ | 00:04.0 | | +| | | | DE:ED:01:0C:DD:CC | | +| | | | | | +| | | +----------+ | | | +| | eth1 +----+ VDE +----+ eth1 pmd_virtio | | +| | virtio | +----------+ | 00:05.0 | | +| | | | DE:ED:02:04:01:60 | | +| | | | | | +| +-------------+ +-------------------+ | +| qemu 2.5 qemu 2.5 | +| | +| | +| Hypervisor | +| Debian 8 | +| Kernel 3.16 | ++-------------------------------------------------------------+ + +Steps +===== + +1. Start a DPDK application using virtio ports +2. Send traffic over those ports (using ping flood ...) +3. Kill this DPDK application (sending SIGKILL, making it crash etc...) +4. Restart this DPDK application with the same configuration +5. During EAL initialization, if an incoming packet is received on a virtio + port, qemu exits (error code 1) with the following message: +> qemu-system-x86_64: Guest moved used index from 571 to 0 + +NOTE: This issue is *NOT* seen with e1000 interface + +Configuration +============= + +Hypervisor +----------- +Debian 8 +Kernel 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 + +Qemu +---- + +qemu 2.5 (vanilla) +./configure --enable-kvm --enable-vhost-net --enable-vde --target-list="x86_64-softmmu" --enable-debug --extra-cflags="-O0 -g" + +> qemu-system-x86_64 -k fr --enable-kvm -m 4G -cpu host -smp \ + sockets=1,cores=1,threads=2 -serial telnet::46528,server,nowait -serial null \ + -qmp tcp::47257,server,nowait -monitor telnet::59305,server,nowait -hda \ + "/opt/vm/ubuntu-14.04-template.qcow2" -snapshot -vga none -display none \ + -netdev vde,id=tapdeed01417a99,sock=L.vdesock -device \ + virtio-net,mac=DE:ED:01:0C:DD:CC,addr=04,netdev=tapdeed01417a99 -netdev \ + vde,id=tapdeed021a7b37,sock=R.vdesock -device \ + virtio-net,mac=DE:ED:02:04:01:60,addr=05,netdev=tapdeed021a7b37 + +On Testnode +----------- + +Configure interface to send continuous traffic to PMD +> ip link set dev eth0 up +> ip addr add 1.1.1.1/24 dev eth0 +> ip neigh add 1.1.1.2 lladdr DE:ED:01:0C:DD:CC dev eth0 +> ping -q -f 1.1.1.2 + +On DUT +------ + +Configure and start testpmd (a standard DPDK application) + +> modprobe uio +> modprobe igb_uio +> mkdir -p /mnt/huge +> mount -t hugetlbfs nodev /mnt/huge +> echo 64 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages +> dpdk_nic_bind --bind=igb_uio 0000:00:04.0 +> dpdk_nic_bind --bind=igb_uio 0000:00:05.0 +> testpmd --huge-dir=/mnt/huge -n 4 -l 0-1 --socket-mem 128 -w 0000:00:04.0 \ + -w 0000:00:05.0 --log-level 8 -- -i --nb-cores=1 --nb-ports=2\ + --total-num-mbufs=1025 +EAL: Detected lcore 0 as core 0 on socket 0 +EAL: Detected lcore 1 as core 0 on socket 0 +EAL: Support maximum 255 logical core(s) by configuration. +EAL: Detected 2 lcore(s) +EAL: Probing VFIO support... +EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory) +EAL: VFIO modules not loaded, skipping VFIO support... +EAL: Setting up physically contiguous memory... +EAL: Ask a virtual area of 0x4600000 bytes +EAL: Virtual area found at 0x7fbcbf000000 (size = 0x4600000) +EAL: Ask a virtual area of 0xc00000 bytes +EAL: Virtual area found at 0x7fbcbe200000 (size = 0xc00000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7fbcbdc00000 (size = 0x400000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcbd800000 (size = 0x200000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcbd400000 (size = 0x200000) +EAL: Ask a virtual area of 0x1c00000 bytes +EAL: Virtual area found at 0x7fbcbb600000 (size = 0x1c00000) +EAL: Ask a virtual area of 0x600000 bytes +EAL: Virtual area found at 0x7fbcbae00000 (size = 0x600000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcbaa00000 (size = 0x200000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcba600000 (size = 0x200000) +EAL: Requesting 64 pages of size 2MB from socket 0 +EAL: TSC frequency is ~3192572 KHz +EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! +EAL: Master lcore 0 is ready (tid=c5707900;cpuset=[0]) +EAL: lcore 1 is ready (tid=c3ffd700;cpuset=[1]) +EAL: PCI device 0000:00:04.0 on NUMA socket -1 +EAL: probe driver: 1af4:1000 rte_virtio_pmd +EAL: PCI memory mapped at 0x7fbcc3600000 +PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11 +PMD: virtio_read_caps(): no modern virtio pci device found. +PMD: vtpci_init(): trying with legacy virtio pci. +PMD: virtio_resource_init_by_uio(): PCI Port IO found start=0xc020 with size=0x20 +PMD: virtio_negotiate_features(): guest_features before negotiate = 100cf8020 +PMD: virtio_negotiate_features(): host_features before negotiate = 79bf8064 +PMD: virtio_negotiate_features(): features after negotiate = 8f8020 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:01:0C:DD:CC +PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported +PMD: virtio_dev_cq_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 2 +PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0 +PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134f35000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaf35000 +PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1 +PMD: eth_virtio_dev_init(): config->status=1 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:01:0C:DD:CC +PMD: eth_virtio_dev_init(): hw->max_rx_queues=1 hw->max_tx_queues=1 +PMD: eth_virtio_dev_init(): port 0 vendorID=0x1af4 deviceID=0x1000 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_cq_start(): VQ: - size=64; free=64; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +EAL: PCI device 0000:00:05.0 on NUMA socket -1 +EAL: probe driver: 1af4:1000 rte_virtio_pmd +EAL: PCI memory mapped at 0x7fbcc3601000 +PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11 +PMD: virtio_read_caps(): no modern virtio pci device found. +PMD: vtpci_init(): trying with legacy virtio pci. +PMD: virtio_resource_init_by_uio(): PCI Port IO found start=0xc040 with size=0x20 +PMD: virtio_negotiate_features(): guest_features before negotiate = 100cf8020 +PMD: virtio_negotiate_features(): host_features before negotiate = 79bf8064 +PMD: virtio_negotiate_features(): features after negotiate = 8f8020 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:02:04:01:60 +PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported +PMD: virtio_dev_cq_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 2 +PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0 +PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134f30000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaf30000 +PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1 +PMD: eth_virtio_dev_init(): config->status=1 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:02:04:01:60 +PMD: eth_virtio_dev_init(): hw->max_rx_queues=1 hw->max_tx_queues=1 +PMD: eth_virtio_dev_init(): port 1 vendorID=0x1af4 deviceID=0x1000 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_cq_start(): VQ: - size=64; free=64; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +Interactive-mode selected +Configuring Port 0 (socket 0) +PMD: virtio_dev_configure(): configure +PMD: virtio_dev_tx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 1 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:512 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134eac000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaeac000 +PMD: virtio_dev_rx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 0 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:128 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134ea6000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaea6000 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +PMD: virtio_dev_rxtx_start(): >> +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_vring_start(): Allocated 256 bufs +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): nb_queues=1 +PMD: virtio_dev_start(): Notified backend at initialization +PMD: virtio_dev_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +rte_eth_dev_config_restore: port 0: MAC address array not supported +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +Port 0: DE:ED:01:0C:DD:CC +Configuring Port 1 (socket 0) +PMD: virtio_dev_configure(): configure +PMD: virtio_dev_tx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 1 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:512 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134ea1000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaea1000 +PMD: virtio_dev_rx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 0 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:128 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134e9c000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbae9c000 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +PMD: virtio_dev_rxtx_start(): >> +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_vring_start(): Allocated 256 bufs +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): nb_queues=1 +PMD: virtio_dev_start(): Notified backend at initialization +PMD: virtio_dev_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +rte_eth_dev_config_restore: port 1: MAC address array not supported +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +Port 1: DE:ED:02:04:01:60 +Checking link statuses... +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +Port 0 Link Up - speed 10000 Mbps - full-duplex +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +Port 1 Link Up - speed 10000 Mbps - full-duplex +Done +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +testpmd> start + io packet forwarding - CRC stripping disabled - packets/burst=32 + nb forwarding cores=1 - nb forwarding ports=2 + RX queues=1 - RX desc=128 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX queues=1 - TX desc=512 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX RS bit threshold=0 - TXQ flags=0xf00 + +... +[wait a few seconds] +... + +Kill the application +> kill -9 $(pidof testpmd) (On another shell) + +Relaunch the application +> testpmd --huge-dir=/mnt/huge -n 4 -l 0-1 --socket-mem 128 -w 0000:00:04.0 \ + -w 0000:00:05.0 --log-level 8 -- -i --nb-cores=1 --nb-ports=2 \ + --total-num-mbufs=1025 +EAL: Detected lcore 0 as core 0 on socket 0 +EAL: Detected lcore 1 as core 0 on socket 0 +EAL: Support maximum 255 logical core(s) by configuration. +EAL: Detected 2 lcore(s) +EAL: Probing VFIO support... +EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory) +EAL: VFIO modules not loaded, skipping VFIO support... +EAL: Setting up physically contiguous memory... +EAL: Ask a virtual area of 0x4400000 bytes +EAL: Virtual area found at 0x7f86cde00000 (size = 0x4400000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7f86cd800000 (size = 0x400000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7f86cd200000 (size = 0x400000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7f86cce00000 (size = 0x200000) +EAL: Ask a virtual area of 0xc00000 bytes +EAL: Virtual area found at 0x7f86cc000000 (size = 0xc00000) +EAL: Ask a virtual area of 0x1c00000 bytes +EAL: Virtual area found at 0x7f86ca200000 (size = 0x1c00000) +EAL: Ask a virtual area of 0x600000 bytes +EAL: Virtual area found at 0x7f86c9a00000 (size = 0x600000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7f86c9400000 (size = 0x400000) +EAL: Requesting 64 pages of size 2MB from socket 0 +... + +VM has been killed by qemu with the following error +> qemu-system-x86_64: Guest moved used index from 570 to 0 + +Debugging +--------- + +With GDB, I have got this backtrace for Qemu + +(gdb) bt full +#0 __GI_exit (status=1) at exit.c:104 +No locals. +#1 0x00007f13cb53412e in virtqueue_num_heads (vq=0x7f13ce28d4c0, idx=592) + at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:320 + num_heads = 64944 +#2 0x00007f13cb53444e in virtqueue_get_avail_bytes (vq=0x7f13ce28d4c0, in_bytes=0x7fff5c036270, + out_bytes=0x7fff5c036274, max_in_bytes=110, max_out_bytes=0) at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:381 + idx = 592 + total_bufs = 0 + in_total = 0 + out_total = 0 +#3 0x00007f13cb5344b6 in virtqueue_avail_bytes (vq=0x7f13ce28d4c0, in_bytes=110, out_bytes=0) + at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:447 + in_total = 1543725744 + out_total = 32767 +#4 0x00007f13cb51ad6b in virtio_net_has_buffers (q=0x7f13ce22cea0, bufsize=110) + at /tmp/qemu/qemu-2.5.0/hw/net/virtio-net.c:899 + n = 0x7f13cda08f18 +#5 0x00007f13cb51b37d in virtio_net_receive (nc=0x7f13cdf96490, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) + at /tmp/qemu/qemu-2.5.0/hw/net/virtio-net.c:1037 + n = 0x7f13cda08f18 + q = 0x7f13ce22cea0 + vdev = 0x7f13cda08f18 + __func__ = "virtio_net_receive" + mhdr_sg = {{iov_base = 0x7f1365fda43e, iov_len = 2}, {iov_base = 0x0, iov_len = 0} <repeats 1023 times>} + mhdr = {hdr = {flags = 0 '\000', gso_type = 0 '\000', hdr_len = 0, gso_size = 0, csum_start = 0, + csum_offset = 0}, num_buffers = 1} + mhdr_cnt = 0 + offset = 98 + i = 1 + guest_offset = 12 + __PRETTY_FUNCTION__ = "virtio_net_receive" +#6 0x00007f13cb75da86 in nc_sendv_compat (nc=0x7f13cdf96490, iov=0x7fff5c057440, iovcnt=1, flags=0) at net/net.c:717 + buf = '\000' <repeats 416 times>... + buffer = 0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b" + offset = 98 +#7 0x00007f13cb75db3e in qemu_deliver_packet_iov (sender=0x7f13cc902eb0, flags=0, iov=0x7fff5c057440, iovcnt=1, + opaque=0x7f13cdf96490) at net/net.c:741 + nc = 0x7f13cdf96490 + ret = 0 +#8 0x00007f13cb75fa5f in qemu_net_queue_deliver (queue=0x7f13cdf966b0, sender=0x7f13cc902eb0, flags=0, + data=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) at net/queue.c:163 + ret = -1 + iov = {iov_base = 0x7fff5c057580, iov_len = 98} +#9 0x00007f13cb75fb7b in qemu_net_queue_send (queue=0x7f13cdf966b0, sender=0x7f13cc902eb0, flags=0, + data=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/queue.c:198 + ret = 139722994604174 +#10 0x00007f13cb75d8d9 in qemu_send_packet_async_with_flags (sender=0x7f13cc902eb0, flags=0, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/net.c:677 + queue = 0x7f13cdf966b0 + ret = 0 +#11 0x00007f13cb75d911 in qemu_send_packet_async (sender=0x7f13cc902eb0, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/net.c:684 +No locals. +#12 0x00007f13cb75d93e in qemu_send_packet (nc=0x7f13cc902eb0, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) at net/net.c:690 +No locals. +#13 0x00007f13cb76b49e in vde_to_qemu (opaque=0x7f13cc902eb0) at net/vde.c:47 + s = 0x7f13cc902eb0 + buf = "[...]" + size = 98 +[...] + +According to GDB, there is no available vring +(gdb) up +#1 0x00007f13cb53412e in virtqueue_num_heads (vq=0x7f13ce28d4c0, idx=592) + at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:320 +320 exit(1); +(gdb) p num_heads +$1 = 64944 +(gdb) p vq->vring.num +$2 = 256 +(gdb) p idx +$3 = 592 +(gdb) p vring_avail_idx(vq) +$5 = 0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1560 b/results/classifier/accel-gemma3:12b/vmm/1560 new file mode 100644 index 000000000..625d63ecc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1560 @@ -0,0 +1,2 @@ + +SLIRP hostfwd_add ignores bind address and uses `INADDR_ANY` diff --git a/results/classifier/accel-gemma3:12b/vmm/1567254 b/results/classifier/accel-gemma3:12b/vmm/1567254 new file mode 100644 index 000000000..dc466132e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1567254 @@ -0,0 +1,34 @@ + +qemu-2.5.1 will not run with gtk3/vte + +Using qemu-2.5.1 and compiling without gtk3 and vte-2.90. + +This works: + +CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local --localstatedir=/var --libexecdir=/usr/local/lib/qemu --interp-prefix=/usr/local/share/qemu --audio-drv-list="oss alsa sdl" --target-list="i386-softmmu i386-linux-user x86_64-softmmu x86_64-linux-user" --smbd=/usr/local/sbin/smbd --disable-curses + +find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \; + +make +sudo make install + +If I then add gtk3 and vte-2.90 development files and compile again, this fails with or without --disable-docs: + + sudo make install +... +make -C po install +make[1]: Entering directory '/usr/src/qemu-2.5.1/po' + GEN tr.mo +/bin/sh: msgfmt: not found +Makefile:13: recipe for target 'tr.mo' failed +make[1]: *** [tr.mo] Error 127 +make[1]: Leaving directory '/usr/src/qemu-2.5.1/po' +Makefile:443: recipe for target 'install' failed +make: *** [install] Error 2 + +If I then add gettext and re-compile, "qemu-system-x86_64 -blah-blah" opens a window, displays the bios message and stops. + +* configure script should check for gettext +* if "--disable-docs" is passed, "make install" should not try to install docs +* qemu should work when compiled with gtk3 and vte +* why does qemu insist on vte-2.90, when vte-2.91 has been out +/- 2 years? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1568621 b/results/classifier/accel-gemma3:12b/vmm/1568621 new file mode 100644 index 000000000..7b96ff35a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1568621 @@ -0,0 +1,19 @@ + +input-linux misdetects Logitech keyboard as a mouse + +The new input-linux.c code misdetects my Logitech K350 keyboard as a mouse. The bug is in the input_linux_complete function. The evdev for this keyboard returns an "evtmap" with the EV_REL bit set. Full evtmap is 0x0012001F. Using a different keyboard everything works as intended, so my configuration and setup are correct otherwise. + + +Suggestion: + +I suggest adding an object property called something like "type" where the user can specify what the device type is manually. This K350 keyboard shows that "evtmap" cannot be used to reliably detect the device type. Since specifying the device type manually is not an undue burden, perhaps it should be a required option and there should be no autodetection? + + +System: + +Arch linux, using qemu-git AUR package installed 20160409. + + +Command line: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/sbin/qemu-system-x86_64 -name win10,debug-threads=on -S -machine pc-i440fx-2.4,accel=kvm,usb=off,vmport=off -cpu host,kvm=off -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 -m 8196 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 58623778-9d9d-4d30-8ec0-b37e12a30fdc -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-17-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/var/lib/libvirt/images/ISOs/Win10_1511_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/ISOs/virtio-win-0.1.112.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sda,format=raw,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:70:8a:db,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=d4:be:d9:56:2e:35,bus=pci.0,addr=0x9 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device vfio-pci,host=04:00.0,id=hostdev0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object input-linux,id=kbd1,evdev=/dev/input/event19,grab_all=on -object input-linux,id=kbb2,evdev=/dev/input/event2 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1571 b/results/classifier/accel-gemma3:12b/vmm/1571 new file mode 100644 index 000000000..edffa5c35 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1571 @@ -0,0 +1,13 @@ + +accel/hvf: Instance size not properly declared +Description of problem: +In [`include/sysemu/hvf.h`](https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/hvf.h#L36), `HVFState` is declared to have the QOM type `TYPE_HVF_ACCEL`; +However, when the type is registered, proper `instance_size` for it was [not declared](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L351). + +As a result, a bad workaround was introduced. That is, when [`hvf_accel_init`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L329) is called from [`accel_init_machine`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/accel-softmmu.c#L33), an new instance of `HVFState` is allocated while we should have used the pre-allocated instance in `ms->accelerator` similar to [what KVM does](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/kvm/kvm-all.c#L2381) (the code didn't do so since the allocated ([using `object_new_with_class`](https://gitlab.com/qemu-project/qemu/-/blob/master/softmmu/vl.c#L2218)) instance didn't allocate enough memory for `HVFState`). + +Eventhough the code wouldn't crash nor have any serious implication, this would leak an `AccelState` and attempts to manually manage accelerators would cause a buffer-overflow. +Steps to reproduce: +1. Run a HVF-accelerated VM +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1571084 b/results/classifier/accel-gemma3:12b/vmm/1571084 new file mode 100644 index 000000000..d434f4b9e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1571084 @@ -0,0 +1,139 @@ + +Qemu 2.x dont build on last Gtk dev 3.0+ + +here the build exit + +ui/gtk.c: In function ‘gd_mouse_set’: +ui/gtk.c:479:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + mgr = gdk_display_get_device_manager(dpy); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:482:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_warp(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ +ui/gtk.c: In function ‘gd_grab_devices’: +ui/gtk.c:1316:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1317:5: error: ‘gdk_device_manager_list_devices’ is deprecated [-Werror=deprecated-declarations] + GList *devs = gdk_device_manager_list_devices(mgr, GDK_DEVICE_TYPE_MASTER); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:41:14: note: declared here + GList * gdk_device_manager_list_devices (GdkDeviceManager *device_manager, + ^ +ui/gtk.c:1327:13: error: ‘gdk_device_grab’ is deprecated: Use 'gdk_seat_grab' instead [-Werror=deprecated-declarations] + gdk_device_grab(dev, win, GDK_OWNERSHIP_NONE, FALSE, + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdnd.h:33:0, + from /usr/local/include/gtk-3.0/gdk/gdkevents.h:34, + from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:31, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevice.h:250:15: note: declared here + GdkGrabStatus gdk_device_grab (GdkDevice *device, + ^ +ui/gtk.c:1330:13: error: ‘gdk_device_ungrab’ is deprecated: Use 'gdk_seat_ungrab' instead [-Werror=deprecated-declarations] + gdk_device_ungrab(dev, GDK_CURRENT_TIME); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdnd.h:33:0, + from /usr/local/include/gtk-3.0/gdk/gdkevents.h:34, + from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:31, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevice.h:259:15: note: declared here + void gdk_device_ungrab (GdkDevice *device, + ^ +ui/gtk.c: In function ‘gd_grab_pointer’: +ui/gtk.c:1392:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1400:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_get_position(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ +ui/gtk.c: In function ‘gd_ungrab_pointer’: +ui/gtk.c:1432:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1434:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_warp(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1577 b/results/classifier/accel-gemma3:12b/vmm/1577 new file mode 100644 index 000000000..5bad61870 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1577 @@ -0,0 +1,85 @@ + +device_del return is already in the process of unplug frequently +Description of problem: +recently we update qemu 6.1.1 to qemu 7.1.0, and run into an issue with the following error: + +command '{ "execute": "device_del", "arguments": { "id": "virtio-diskX" } }' for VM "id" failed ({ "return": {"class": "GenericError", "desc": "Device virtio-diskX is already in the process of unplug"} }). + +The issue is reproducible. With a few seconds delay before hot-unplug, hot-unplug just works fine. + +After a few digging, we found that the commit 9323f892b39 may incur the issue. +------------------ + failover: fix unplug pending detection + + Failover needs to detect the end of the PCI unplug to start migration + after the VFIO card has been unplugged. + + To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in + pcie_unplug_device(). + + But since + 17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") + we have switched to ACPI unplug and these functions are not called anymore + and the flag not set. So failover migration is not able to detect if card + is really unplugged and acts as it's done as soon as it's started. So it + doesn't wait the end of the unplug to start the migration. We don't see any + problem when we test that because ACPI unplug is faster than PCIe native + hotplug and when the migration really starts the unplug operation is + already done. + + See c000a9bd06ea ("pci: mark device having guest unplug request pending") + a99c4da9fc2a ("pci: mark devices partially unplugged") + + Signed-off-by: Laurent Vivier <lvivier@redhat.com> + Reviewed-by: Ani Sinha <ani@anisinha.ca> + Message-Id: <20211118133225.324937-4-lvivier@redhat.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +------------------ +The purpose is for detecting the end of the PCI device hot-unplug. However, we feel the error confusing. How is it possible that a disk "is already in the process of unplug" during the first hot-unplug attempt? So far as I know, the issue was also encountered by libvirt, but they simply ignored it: + + https://bugzilla.redhat.com/show_bug.cgi?id=1878659 + +Hence, a question is: should we have the line below in acpi_pcihp_device_unplug_request_cb()? + + pdev->qdev.pending_deleted_event = true; + +It would be great if you as the author could give us a few hints. + +Thank you very much for your reply! + +Sincerely, + +Yu Zhang @ Compute Platform IONOS + + +The issue is reproducible in our own stack, which is not quite easy to describe in a few command lines. We simplified it a bit by a script instead. Although it's not able to reproduce, it could be somewhat helpful to understand the issue. + +``` +#!/bin/bash + +HOME=~ +QEMU=$HOME/qemu/bin/qemu-system-x86_64 +DISK1=$HOME/img/disk1.qcow2 +DISK4=$HOME/img/disk4.qcow2 +DISK5=$HOME/img/disk5.qcow2 + +$QEMU \ + -cpu host -enable-kvm -m 2048 -smp 2 \ + -object iothread,id=iothread1 \ + -drive file=$DISK1,if=none,id=drive-virtio-disk1,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,iothread=iothread1,num-queues=1,discard=on,id=virtio-disk1 \ + -object iothread,id=iothread4 \ + -drive file=$DISK4,if=none,id=drive-virtio-disk4,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk4,iothread=iothread4,num-queues=1,discard=on,id=virtio-disk4 \ + -object iothread,id=iothread5 \ + -drive file=$DISK5,if=none,id=drive-virtio-disk5,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk5,iothread=iothread5,num-queues=1,discard=on,id=virtio-disk5 \ + -qmp unix:./qmp-sock,server,nowait & + +sleep 5 + +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock``` +Additional information: +Possible workaround: https://lore.kernel.org/qemu-devel/20230403131833-mutt-send-email-mst@kernel.org/T/#t diff --git a/results/classifier/accel-gemma3:12b/vmm/1581976 b/results/classifier/accel-gemma3:12b/vmm/1581976 new file mode 100644 index 000000000..628632a5f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1581976 @@ -0,0 +1,17 @@ + +man qemu contains a bug in description of "-virtfs" command line argument + +The description of command line argument looks like this: + + -virtfs + fsdriver[,path=path],mount_tag=mount_tag[,security_model=security_model][,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd] + + +note, that there is no "id" attribute in the list of parameters. + +later on the man there the "id" attribute is documented, as it were present: + + id=id + Specifies identifier for this device + +i think that it was copied from above section (about "-fsdev") without reviewing. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1585 b/results/classifier/accel-gemma3:12b/vmm/1585 new file mode 100644 index 000000000..1658d7292 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1585 @@ -0,0 +1,28 @@ + +Incorrect VGA text mode rendering +Description of problem: +All of my physical machines use black as `DarkGray` and have the text starting from `White+DarkGray` blink (watch the video below). The ISO I'm using is a minimal kernel I've written to check VGA text mode (provided by the BIOS at `0xb8000` with a 80x25 resolution) handling on multiple emulators and machines. +Changing the emulated CPU and display driver doesn't change this behaviour. + +Hyper-V: color test shows correct colors, all text starting from `White+DarkGray` is blinking + + + +AMD Athlon 64 X2 6000+ + NVIDIA Quadro 400 on actual hardware: same as Hyper-V +I've tested this with multiple physical GPUs and they all have the same behaviour and color palette. + + + +QEMU: dark gray is the wrong color and the text doesn't blink +Changing the emulated device doesn't change this behaviour. + + + +I think QEMU should emulate the hardware as close as possible and therefore atleast have the blinking text. +Consider this a low priority issue. +Steps to reproduce: +1. Download ISO from the link above +2. Run the QEMU command above +3. See the text not blink +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1585432 b/results/classifier/accel-gemma3:12b/vmm/1585432 new file mode 100644 index 000000000..85742052e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1585432 @@ -0,0 +1,11 @@ + +magnum coe-service-list returns error + +magnum running on centos7, + +I didn't create any services on k8s cluster, + +but I got the result as follows: + +[root@localhost ~(keystone_admin)]# magnum coe-service-list --bay k8sbay3 +ERROR: Field `ports[0][node_port]' cannot be None (HTTP 500) (Request-ID: req-c66b68dd-5437-47fa-a389-7cb56a262fa5) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1585433 b/results/classifier/accel-gemma3:12b/vmm/1585433 new file mode 100644 index 000000000..9ec7006d3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1585433 @@ -0,0 +1,11 @@ + +if docker-volume-size of baymodel lessthan 3, bay cann't create + +magnum is running on centos7, + + +magnum baymodel-create --name k8sbaymodel5 --image-id fedora-23-atomic-20160405 --keypair-id testkey --external-network-id public --dns-nameserver 8.8.8.8 --flavor-id m1.small --coe kubernetes --docker-volume-size 5 + +magnum bay-create --name k8sbay5 --baymodel k8sbaymodel5 --node-count 1 + +Execute the above command can get a completed bay,but when docker-volume-size is 1 or 2,the status of bay is FAILED. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1585533 b/results/classifier/accel-gemma3:12b/vmm/1585533 new file mode 100644 index 000000000..d82dd67a8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1585533 @@ -0,0 +1,15 @@ + +cache-miss-rate / Invalid JSON + +Hi, + +We have VMs which were started with an older version than qemu 2.1 which added "cache-miss-rate" property for XBZRLECacheStats. While trying to migrate the VM to a new host which is running a higher version (2.3) of Qemu we got an exception: + +virJSONValueFromString:1642 : internal error: cannot parse json {"return": {"expected-downtime": 1, "xbzrle-cache": {"bytes": 0, "cache-size": 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0, "cache-miss": 8933}, "status": "active", "disk": {"total": 429496729600, "dirty-sync-count": 0, "remaining": 193896382464, "mbps": 0, "transferred": 235600347136, "duplicate": 0, "dirty-pages-rate": 0, "skipped": 0, "normal-bytes": 0, "normal": 0}, "setup-time": 13, "total-time": 1543124, "ram": {"total": 8599183360, "dirty-sync-count": 4, "remaining": 30695424, "mbps": 830.636997, "transferred": 3100448901, "duplicate": 1358341, "dirty-pages-rate": 7, "skipped": 0, "normal-bytes": 3082199040, "normal": 752490}}, "id": "libvirt-186200"}: lexical error: malformed number, a digit is required after the minus sign. + 67108864, "cache-miss-rate": -nan, "pages": 0, "overflow": 0 + (right here) ------^ + +virNetClientStreamRaiseError:191 : stream aborted at client request + + +Would it be possible to improve the JSON parser to skip the key if the value is incorrect instead of throwing an exception? Then hopefully qemu 2.3 or higher is able to handle the data without this property, falling back to its default. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1586194 b/results/classifier/accel-gemma3:12b/vmm/1586194 new file mode 100644 index 000000000..14c2b0207 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1586194 @@ -0,0 +1,47 @@ + +VNC reverse broken in qemu 2.6.0 + +Hi all, + +I recently tried to upgrade from Qemu 2.4.1 to 2.6.0, but found some problems with VNC reverse connections. + +1) In "-vnc 172.16.1.3:5902,reverse" used to mean "connect to port 5902" + That seems to have changed changed since 2.4.1, the thing after the IP address is now interpreted + as a display number. If that change was intentional, the man-page needs to be fixed. + +2) After subtracting 5900 from that port number (-vnc 172.16.1.3:2,reverse), I ran into a segfault. + +---8<--- +Program received signal SIGSEGV, Segmentation fault. +qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7fffffffe118) at io/channel-socket.c:33 +33 return socket_sockaddr_to_address(&ioc->localAddr, +(gdb) bt +#0 qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7fffffffe118) at io/channel-socket.c:33 +#1 0x000055555594c0f5 in vnc_init_basic_info_from_server_addr (errp=0x7fffffffe118, info=0x555558f35990, + ioc=<optimized out>) at ui/vnc.c:146 +#2 vnc_server_info_get (vd=0x7fffecc4b010) at ui/vnc.c:223 +#3 0x000055555595192a in vnc_qmp_event (vs=0x555558f41f30, vs=0x555558f41f30, event=QAPI_EVENT_VNC_CONNECTED) + at ui/vnc.c:279 +#4 vnc_connect (vd=vd@entry=0x7fffecc4b010, sioc=sioc@entry=0x555558f34c00, skipauth=skipauth@entry=false, + websocket=websocket@entry=false) at ui/vnc.c:2994 +#5 0x00005555559520d8 in vnc_display_open (id=id@entry=0x555556437650 "default", errp=errp@entry=0x7fffffffe228) + at ui/vnc.c:3773 +#6 0x0000555555952fd3 in vnc_init_func (opaque=<optimized out>, opts=<optimized out>, errp=<optimized out>) + at ui/vnc.c:3868 +#7 0x0000555555a011da in qemu_opts_foreach (list=<optimized out>, func=0x555555952fa0 <vnc_init_func>, opaque=0x0, + errp=0x0) at util/qemu-option.c:1116 +#8 0x00005555556dcfbe in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4592 +--->8--- + +A git bisect shows that this happens since + +---8<--- +commit 98481bfcd661daa3c160cc87a297b0e60a307788 +Author: Eric Blake <email address hidden> +Date: Mon Oct 26 16:34:45 2015 -0600 + + vnc: Hoist allocation of VncBasicInfo to callers +--->8--- + +TIA + Andi \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1590322 b/results/classifier/accel-gemma3:12b/vmm/1590322 new file mode 100644 index 000000000..0aedd624a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1590322 @@ -0,0 +1,11 @@ + +mouse_button 0 takes back to initial position + +i wrote a python script to perform some drag function in the Qemu simulator. +mouse_move x , y +mouse_button 1 +mouse_move new_x,new_y +mouse_move 0 + + +The mouse_move 0 doesn't release the mouse in the position new_x,new_y instead it takes it back to the point x,y and then releases the mouse \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1591628 b/results/classifier/accel-gemma3:12b/vmm/1591628 new file mode 100644 index 000000000..5cd503ea4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1591628 @@ -0,0 +1,45 @@ + +2.6.0 hangs linux vm using vfio for pci passthrough of graphics card + +Not a duplicate of my old bug 1488363 + +qemu version 2.5.1 works fine +qemu version 2.6.0 fails + +seabios 1.9.2-1 + +using kernel 4.5.5 with grsecurity + +I built using the arch packaging tools, but commented out all the patch code, so it should be vanilla. + +The problem is just that I start a Linux vm using either my radeon R7 260x or radeon HD 6770, and with qemu 2.6.0, it looks normal until after the grub menu, and then the screen looks broken (with mostly black, and some pixely junk spread horizontally in a few places on the screen... first we thought maybe the monitor died). I'm not sure if it's before or only at the moment where the screen resolution changes (I could check that or record it on request). Also, the VM is not pingable and does not respond to "system_powerdown" on qemu monitor. + +However, the same setup works fine with windows 8. And it works fine without graphics cards passed through. A usb controller passed through works fine too. + + +And then I ran a bisect... + + 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 is the first bad commit + commit 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 + Author: Alex Williamson <email address hidden> + Date: Thu Mar 10 09:39:08 2016 -0700 + + vfio/pci: Convert all MemoryRegion to dynamic alloc and consistent functions + + Match common vfio code with setup, exit, and finalize functions for + BAR, quirk, and VGA management. VGA is also changed to dynamic + allocation to match the other MemoryRegions. + + Signed-off-by: Alex Williamson <email address hidden> + + :040000 040000 0acfd49b6ecae780b6f52a34080ecec6b3ec3672 e0cfdadede08f553463c0b23931eda81107f41b8 M hw + +then confirm it by reverting that commit + git checkout v2.6.0 + git revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 + git mergetool -t kdiff3 + "select all from C", save + not sure if this is the right way to do this...but it compiles and works (bug fixed) + git commit -m "revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 resolve conflicts" + +And that 2.6.0 build with that one patch reverted works fine. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1592315 b/results/classifier/accel-gemma3:12b/vmm/1592315 new file mode 100644 index 000000000..96cab627e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1592315 @@ -0,0 +1,62 @@ + +Windows 10 continuous screen refresh if resize guest to match window size is selected with QXL + +When VDA-Agent starts up, I get a continuous flicker of the screen. This is almost like a screen refresh, where I am not even able to really click on things and/or open menus. + +Running Windows 10, x64 + +app-emulation/spice-0.13.1-r2::gentoo +net-misc/spice-gtk-0.31::gentoo +app-emulation/spice-protocol-0.12.11::gentoo +app-emulation/qemu--2.6.0::gentoo +nvidia-drivers-367.18 +xorg-server-1.18.3 + +Kernel string: + +Linux wks-ros 4.4.11 #6 SMP PREEMPT Mon May 30 00:01:35 MDT 2016 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux + +Launch string: + +SPICE_PORT=5924 +DRIVERS_IMG=media/virtio-win-0.1.118.iso +SYSTEM_DISK=system.disk +BIOS_ROM="OVMF.fd" +DVDROM_DRIVE="/dev/sr0" +VM_NAME="Windows 10 x64 VM" + +/usr/bin/qemu-system-x86_64 \ + -machine accel=kvm \ + -acpitable file="acpi_slic.bin" \ + -bios "${BIOS_ROM}" \ + -no-shutdown \ + -cpu qemu64,+ssse3,+sse4.1,+sse4.2 \ + -smp cpus=2,sockets=2,cores=1,threads=1 \ + -m 16G \ + -realtime mlock=off \ + -drive file="${SYSTEM_DISK}",if=virtio \ + -spice port=${SPICE_PORT},addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ + -chardev spicevmc,id=charchannel0,name=vdagent \ + -device virtio-serial-pci -chardev spicevmc,id=vdagent,debug=0,name=vdagent \ + -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ + -device qxl-vga,id=video0 \ + -device virtio-balloon-pci,id=balloon0 \ + -rtc base=localtime,driftfix=slew \ + -name "${VM_NAME}" & exec spicy --title "${VM_NAME}" 127.0.0.1 -p ${SPICE_PORT} + + + +Some additional interesting things I've observed: + +* If the QXL driver is not installed, then the flicker doesn't happen +* As soon as i enable the VDA Agent, the annoying flicker / screen refresh begins +* When I disable the VDA Agent, same thing happens. + +- I tried Windows-Guest-Tools-0.100 and version 0.0103-r1 + +- And an assortment of QXL drivers, (WDM, proper for Windows 10). + + +As a workaround, I can set "Scale display" to On, and "Resize Guest to Match" to off (using Spicy-gtk). This stops the flicker. + +- Another strange thing is that I my XQL driver in Windows shows 8GB of Video mem. I am not sure how/why this is, as I have not seen this before. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1593756 b/results/classifier/accel-gemma3:12b/vmm/1593756 new file mode 100644 index 000000000..d3299e980 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1593756 @@ -0,0 +1,18 @@ + +qemu-ga won't start on Windows 8.1 guest + +System: Arch Linux, kernel 4.6.2 +VM created with virt-manager 1.3.2 +qemu version 2.6.0 +Windows guest: 8.1, with latest updates (as of now) +Drivers installed from virtio-win iso image (arch package version 0.1.118.2-1) + in particular: vioserial driver version 62.73.104.11800 + +I can start the Guest Agent VSS Provider manually, but the Guest Agent itself doesn't come up. When launched from Console, I get the following: + +<timestamp>: critical: error opening path +<timestamp>: critical: error opening channel +<timestamp>: critical: failed to create guest agent channel +<timestamp>: critical: failed to initialize guest agent channel + +(As possible side effects I have experienced that suspend / resume of the VM only works when I resume, suspend again and resume again. After first resume the VM's screen is frozen and doesn't accept any input. After second resume, all seems to be well.) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1594 b/results/classifier/accel-gemma3:12b/vmm/1594 new file mode 100644 index 000000000..da7468fa5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1594 @@ -0,0 +1,22 @@ + +Wrong cpu information is still received when using whpx acceleration. +Description of problem: +I received wrong information the other day and registered an issue, but now the latest version has not been fixed and is delivering the same wrong information. +If not fixed, Windows Home version (Windows 11 Home version) cannot run more than 5 cores with whpx acceleration. +(If you boot after setting more than 5 cores, an incorrect CPU parameter BSOD occurs during booting, and Windows 11 home version seems to allow up to 4 physical CPUs..) +* Even if you explicitly give -smp cores=n,threads=1,sockets=1 and boot, it is ignored and recognized as a PC with n 1-core CPUs. +Steps to reproduce: +1. Run qemu with -accel whpx option +2. Check CPU information after booting is complete +3. Check the same CPU information after booting from a physical PC and other virtualization software (VMware, Virtual Box, etc.) +4. It has been confirmed that the number of physical CPUs and the number of cores per CPU are different from other virtualization software or physical PCs. (For example, when setting 4 cores, it is recognized as 1CPU 4Core in other virtualization software, but as 4CPU 1Core in qemu operated with whpx acceleration) +Additional information: +* The CPU was set to 4 cores, and the image was taken as a screenshot of the information recognized as the 4th processor by Linux. +> Linux CPU information booted from qemu (with whpx acceleration) +execution statement : qemu-system-x86_64 -M q35 -smp cores=4,threads=1,sockets=1 -m 4g -display sdl -drive file=test.vdi,id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -accel whpx (or 'qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -drive file=test.vdi,id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -accel whpx') + + + +> Linux CPU information booted from other virtualization software (Virtual Box) + + diff --git a/results/classifier/accel-gemma3:12b/vmm/1597138 b/results/classifier/accel-gemma3:12b/vmm/1597138 new file mode 100644 index 000000000..d1661f6b5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1597138 @@ -0,0 +1,13 @@ + +Deadlock on Windows 10 pop-up + +I was able to install and can log in but whenever a pop-up is attempted the VM appears to deadlock. +I can still kill -9 the process and recover but the VM and the QEmu console both hang with no error output. + +At first I thought it was UAC but renaming a file causes a pop-up and that also deadlocks. +I rebuilt QEmu 2.6.0 with debug info and did a thread back-trace once the deadlock occurs. +See the attachment for the trace. + +I am attempting to setup GPU pass-thru with a GTX 970 but this deadlock occurs with -vga std (and no GPU pass-thru) as well. + +(I cannot install or start Windows 7 but I am told this is a known bug.) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1599214 b/results/classifier/accel-gemma3:12b/vmm/1599214 new file mode 100644 index 000000000..b0dcc9d0f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1599214 @@ -0,0 +1,23 @@ + +virtlogd: qemu 2.6.0 doesn't log boot message + +This report is related to the OpenStack Nova bug [1]. + +OpenStack tries to utilize the "virtlogd" feature of qemu [2]. + +steps to reproduce: +1) launch a quest with qemu 2.6.0 which uses virtlogd for the stdout/stderr of its char device +2) check the contents of the backing file of that char device + +expected result: +The boot messages of the guest are logged in this file + +actual result: +The file is empty + +notes: +When I'm connected to that char device and reboot the guest, I see the boot messages in the terminal and also in the backing log file. + +References: +[1] https://bugs.launchpad.net/nova/+bug/1597789 +[2] http://git.qemu.org/?p=qemu.git;a=blobdiff;f=qemu-char.c;h=11caa5648de99c9e0ee158f280fbc02ab05915d3;hp=d7be1851e5e9d268aa924a05958da292b048839c;hb=d0d7708ba29cbcc343364a46bff981e0ff88366f;hpb=f1c17521e79df863a5771d96974fab0d07f02be0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1600 b/results/classifier/accel-gemma3:12b/vmm/1600 new file mode 100644 index 000000000..b64f67c1f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1600 @@ -0,0 +1,26 @@ + +Aarch64/FEAT_SEL2 secure S1 translation for a NS page resolves to the secure IPA space +Description of problem: +Follow up to https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmware.org/thread/ZUHRGWVDPUQ5CK6SRWZ7AMI5IKVS6J47/ + +In context of Hafnium project (SEL2 / SPM firmware), implementing secure/non-secure page tables split rooted by VTTBR/VSTTBR in TZ secure world. +Observing transactions always resolve to the secure IPA space (hence to the page tables rooted to by VSTTBR) whichever the state of the S1 MMU translation NS bit. +Access to a page mapped NS from the SEL1 Trusted OS, causes a S2 page fault even though mapped in page tables rooted to by VTTBR. + +The VTCR_EL2/VSTCR_EL2 settings at SEL2 are as follows: +VTCR_EL2.NSA/NSW=10b +VSTCR_EL2.SA/SW=00b + +Note the same set of changes (https://review.trustedfirmware.org/q/topic:%2522od/split-vttbr%2522+status:open) run fine for the same scenario on FVP. +Steps to reproduce: +1. build qemu master 60ca584b8af0de525656f959991a440f8c191f12 +2. unzip [qemu-sel2-vttbr-fail.zip](/uploads/ec556347c32d97f79c140c5bccf45c6b/qemu-sel2-vttbr-fail.zip) +3. Run + +``` +<...>/qemu/build/aarch64-softmmu/qemu-system-aarch64 -nographic -serial file:uart0.log -serial file:uart1.log -smp 2 -machine virt,secure=on,mte=on,gic-version=3,virtualization=true -cpu max,sme=off,pauth-impdef=on -d unimp -semihosting-config enable=on,target=native -m 1057 -bios bl1.bin -initrd rootfs.cpio.gz -kernel Image -no-acpi -append 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 nokaslr' -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 -netdev user,id=vmnic -device virtio-net-device,netdev=vmnic +``` +Additional information: +[qemu-60ca58-qemu-tfa-hf-linux-fail.txt](/uploads/1db0155fc49140cf52913cd75b7494c1/qemu-60ca58-qemu-tfa-hf-linux-fail.txt) illustrates the failure, linux boot stops, after sharing a NS page to the TOS, and the TOS retrieving the page, mapping as NS and accessing it (ends in a dead loop, because of the S2 PF in the TOS). + +[qemu-tfa-hf-linux-pass.txt](/uploads/4e672617838e40fe3614c127531443b5/qemu-tfa-hf-linux-pass.txt) shows the expected output where the NS mem sharing operation succeeds. diff --git a/results/classifier/accel-gemma3:12b/vmm/1602 b/results/classifier/accel-gemma3:12b/vmm/1602 new file mode 100644 index 000000000..b82c5e69a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1602 @@ -0,0 +1,8 @@ + +github.com/qemu/qemu has been out of sync with GitLab since Mar 23, 2023 +Description of problem: +https://github.com/qemu/qemu has been out of sync with https://gitlab.com/qemu-project/qemu since Mar 23, 2023. +Steps to reproduce: +See https://github.com/qemu/qemu +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1603 b/results/classifier/accel-gemma3:12b/vmm/1603 new file mode 100644 index 000000000..c138fb8a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1603 @@ -0,0 +1,74 @@ + +Regression in v8.0.0-rc1: `Abort trap: 6` during `hvf/x86_emu.c:exec_mov()` (`-cpu host` + UEFI) +Description of problem: +`qemu-system-x86_64 -accel hvf -cpu host -drive <UEFI>` crashes. +Steps to reproduce: +```console +$ qemu-system-x86_64 -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd +vmx_read_mem: mmu_gva_to_gpa ffc00000 failed +Abort trap: 6 +``` +Additional information: +This is a regression in v8.0.0-rc1. + +- v8.0.0-rc0: works +- v8.0.0-rc1: crashes +- ... +- v8.0.0-rc4: crashes + + +Backtrace: +```console +$ lldb /usr/local/bin/qemu-system-x86_64 +(lldb) target create "/usr/local/bin/qemu-system-x86_64" +Current executable set to '/usr/local/bin/qemu-system-x86_64' (x86_64). +(lldb) process handle SIGUSR2 -s false -p true +NAME PASS STOP NOTIFY +=========== ======= ======= ======= +SIGUSR2 true false not set +(lldb) run -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd +Process 17627 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64) +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +2023-04-14 17:16:22.879194+0900 qemu-system-x86_64[17627:1529741] [Window] Warning: Window NSWindow 0x10391def0 ordered front from a non-active application and may order beneath the active application's windows. +vmx_read_mem: mmu_gva_to_gpa ffc00000 failed +Process 17627 stopped +* thread #4, stop reason = signal SIGABRT + frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10 +libsystem_kernel.dylib`: +-> 0x7ff8121331f2 <+10>: jae 0x7ff8121331fc ; <+20> + 0x7ff8121331f4 <+12>: movq %rax, %rdi + 0x7ff8121331f7 <+15>: jmp 0x7ff81212ccdb ; cerror_nocancel + 0x7ff8121331fc <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #4, stop reason = signal SIGABRT + * frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007ff81216aee6 libsystem_pthread.dylib`pthread_kill + 263 + frame #2: 0x00007ff812091b45 libsystem_c.dylib`abort + 123 + frame #3: 0x0000000100223608 qemu-system-x86_64`vmx_read_mem + 201 + frame #4: 0x000000010021fa5b qemu-system-x86_64`read_val_ext + 65 + frame #5: 0x000000010021fc02 qemu-system-x86_64`fetch_operands + 197 + frame #6: 0x0000000100220f8b qemu-system-x86_64`exec_mov + 31 + frame #7: 0x0000000100220f01 qemu-system-x86_64`exec_instruction + 48 + frame #8: 0x000000010021c81f qemu-system-x86_64`hvf_vcpu_exec + 4144 + frame #9: 0x000000010033fa53 qemu-system-x86_64`hvf_cpu_thread_fn + 270 + frame #10: 0x0000000100492e49 qemu-system-x86_64`qemu_thread_start + 130 + frame #11: 0x00007ff81216b1d3 libsystem_pthread.dylib`_pthread_start + 125 + frame #12: 0x00007ff812166bd3 libsystem_pthread.dylib`thread_start + 15 +(lldb) +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1603693 b/results/classifier/accel-gemma3:12b/vmm/1603693 new file mode 100644 index 000000000..de99632ae --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1603693 @@ -0,0 +1,78 @@ + +Disks in mptsas1068 scsi controller not seen by linux + +When using the mptsas1068 scsi controller, linux detects the controller itself but not the drives attached to it. Freebsd works. Using a different controller with linux works. VMware with linux works. + +qemu 2.6.50 (v2.6.0-1925-g6b92bbf) +seabios rel-1.9.0-139-gae3f78f (master branch, required for mptsas1068 support) + +Test script, loosely based off what libvirt runs and the libvirt tests that Paolo Bonzini wrote [1] + +##################### +iso=archlinux-2016.07.01-dual.iso +#iso=FreeBSD-10.3-RELEASE-amd64-bootonly.iso +device=mptsas1068 +#device=lsi + +img=empty.img +qemu-img create -f qcow2 $img 1G + +/usr/bin/qemu-system-x86_64 \ +-enable-kvm \ +-m 1024 \ +-boot menu=on \ +-device $device,id=scsi0,bus=pci.0,addr=0x9 \ +-drive file=$img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 \ +-drive file=$iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 +##################### + +The ISOs can be downloaded from [2] and [3]. + +After booting linux, do "lsblk". /dev/sda should exist. + +After booting freebsd, do "geom disk list". A da0 / "QEMU QEMU HARDDISK" should be mentioned. + +With device=mptsas1068 this fails in linux. + +With device=lsi line it works in both. + +With VMWare and a linux VM (opensuse 10.1, kernel 2.6.18) which only loads modules for mptsas1068, this works. + +I also reproduced this with the debian 8.5 netinstall image, but it insists in making you pick a driver from a list of modules when it fails to mount it, instead of dropping to a shell. + +Arch linux dmesg output snippet (full output attached as arch-linux-dmesg.txt): + +##################### +root@archiso ~ # dmesg | grep -i -e mpt -e scsi -e ioc0 +[ 0.000000] Linux version 4.6.3-1-ARCH (builduser@tobias) (gcc version 6.1.1 20160602 (GCC) ) #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 +[ 0.000000] Normal empty +[ 0.000000] Preemptible hierarchical RCU implementation. +[ 1.879616] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 1.951581] SCSI subsystem initialized +[ 1.957113] Fusion MPT base driver 3.04.20 +[ 1.957618] Fusion MPT SAS Host driver 3.04.20 +[ 2.281773] scsi host0: ata_piix +[ 2.285372] scsi host1: ata_piix +[ 2.305803] mptbase: ioc0: Initiating bringup +[ 2.363555] ioc0: LSISAS1068 A0: Capabilities={Initiator} +[ 2.444390] scsi 0:0:1:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +[ 2.500572] scsi host2: ioc0: LSISAS1068 A0, FwRev=01329200h, Ports=8, MaxQ=128, IRQ=11 +[ 2.507024] sr 0:0:1:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[ 2.507274] sr 0:0:1:0: Attached scsi CD-ROM sr0 +##################### + +The controller itself is detected, the disk isn't. + +An early version of this patch [4] said that it was only tested with FreeBSD: + +>Tested with FreeBSD for now. The previous version (before the +>configuration page rewrite) worked with RHEL and Windows guests as well. +> +>TODO: write qtest for (at least) config pages, test Linux and Windows. + +[1]: https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=fc922eb2080a3fa7b24bc8a8b0aabfd394480143 +[2]: https://www.archlinux.org/download +[3]: https://www.freebsd.org/where.html +[4]: https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06475.html \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1605 b/results/classifier/accel-gemma3:12b/vmm/1605 new file mode 100644 index 000000000..1cb62ba8a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1605 @@ -0,0 +1,39 @@ + +On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +Description of problem: +On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +- qemu windows crashes during data copy + ```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios D:\vstorage\win_m01_edk2-x8_64.fd -boot c -drive "index=0,if=virtio,media=disk,format=raw,file=D:\vstorage\m01_bootnoefi.raw.img" -drive "index=1,if=virtio,media=disk,format=raw,file=F:\m01_lnx.raw.img.vtoy" -drive "index=2,if=virtio,media=disk,format=vhdx,file=F:\gkpics01.vhdx" -drive "index=3,if=virtio,media=disk,format=vhdx,file=D:\test\sgdata.vhdx" -display sdl -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on -device virtio-serial -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait"``` + ``` ``` + ```Windows Hypervisor Platform accelerator is operational``` + ```Unexpected error in bdrv_check_qiov_request() at ../../../block/io.c:815:``` + ```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64.exe: offset is negative: -28983296``` + +. +- The **LINE NUMBER** : https://gitlab.com/qemu-project/qemu/-/blob/master/block/io.c#L815 +- qemu setup is ```qemu-w64-setup-20230414.exe ``` +Steps to reproduce: +1. have fresh vhdx ready create a vhdx in ```diskmgmt``` (also attached to [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_1346341805)) +2. have vhdx with synthetic generated data ready (see process to generate sgdata in [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694) ) +3. start qemu, login, open terminal +4. Inside VM, start a terminal window, sudo root, +5. open```gdisk /dev/vdc``` create a ntfs partition +6. format as ntfs: ```mkfs.ntfs -Q -L fs_gkpics01 /dev/vdc1``` +7. mount the partition ```mount -t ntfs3 /dev/vdc1 /mnt/a -o uid=1000,gid=1000,defaults,umask=0002``` +8. mount the partition ```mount -t ntfs3 /dev/vdd2 /mnt/b -o uid=1000,gid=1000,defaults,umask=0002``` +9. In a user login, do rsync data-copy step + ```( fl="photos001" ; src="/mnt/b/sgdata" ; dst="/mnt/a" ; sdate=`date` ; echo "$sdate" ; cd "$src" ; rsync -avH "$fl" "$dst" ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" )``` + + +The bug is easily reproducible. +The moment of the crash may seems spurious, but is almost certainly bound to happen. +When it happens, it can be seen to be the same error message. +Sometimes the crash happens in ```gdisk``` step, sometimes during ```mkfs.ntfs``` sometimes partway through the ```rsync```-copy, not very long into it. +Additional information: +- This has been happening for some time. I haven't used/tested vhdx much in windows much since 7.0.0 on account of other corruption bugs/lack of dependability. +- This does not happen in Linux, as tested in #727 +- The fix of #727 is unrelated to this. It doesn't have the same feel/reproduction intuitive-signature. + - Happens before (on doing the same test) + - on 8.0.0-rc1 (line number of io.c there is L811) + - on 7.2.0 (line no of io.c there is [L971](https://gitlab.com/qemu-project/qemu/-/blob/ace5a161ea1c09d8eaa8b2a717528457dc924e83/block/io.c#L971)) +- It may be caused by other changes going into block code since 7.0 . diff --git a/results/classifier/accel-gemma3:12b/vmm/1605045 b/results/classifier/accel-gemma3:12b/vmm/1605045 new file mode 100644 index 000000000..dd1702698 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1605045 @@ -0,0 +1,4 @@ + +input-linux enter key stuck and/or broken + +Using new input-linux evdev passthrough feature of qemu (qemu 2.6.0) causes enter key to be stuck down after executing a shell script to launch qemu guest, resulting in repeated new lines in terminal. After a certain point of guest boot, the enter key is no longer pressed. However, at least under Gnome on Wayland, when pressing both left+right Ctrl keys to return keyboard back to the host, the enter key no longer functions. The enter key continues to function when control is under the guest, but never returns to functionality in the host until a reboot is performed. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1607 b/results/classifier/accel-gemma3:12b/vmm/1607 new file mode 100644 index 000000000..505ec88cb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1607 @@ -0,0 +1,2 @@ + +QEMU calls glXMakeCurrent which is current in another thread when running VM with SDL diff --git a/results/classifier/accel-gemma3:12b/vmm/1609968 b/results/classifier/accel-gemma3:12b/vmm/1609968 new file mode 100644 index 000000000..bac735da3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1609968 @@ -0,0 +1,32 @@ + +"cannot set up guest memory" b/c no automatic clearing of Linux' cache + +Version: qemu-2.6.0-1 +Kernel: 4.4.13-1-MANJARO +Full script (shouldn't matter though): https://pastebin.com/Hp24PWNE + +Problem: +When host has been up and used for a while cache has been filled as much that guest can't be started without droping caches. + +Expected behavior: +Qemu should be able to request as much Memory as it needs and cause Linux to drop cache pages if needed. A user shouldn't be required to have to come to this conclusion and having to drop caches to start Qemu with the required amount of memory. + +My fix: +Following command (as root) required before qemu start: +# sync && echo 3 > /proc/sys/vm/drop_caches + +Example: +$ sudo qemu.sh -m 10240 && echo success || echo failed +qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory +failed +$ free + total used free shared buff/cache available +Mem: 16379476 9126884 3462688 148480 3789904 5123572 +Swap: 0 0 0 +$ sudo sh -c 'sync && echo 3 > /proc/sys/vm/drop_caches' +$ free + total used free shared buff/cache available +Mem: 16379476 1694528 14106552 149772 578396 14256428 +Swap: 0 0 0 +$ sudo qemu.sh -m 10240 && echo success || echo failed +success \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1610 b/results/classifier/accel-gemma3:12b/vmm/1610 new file mode 100644 index 000000000..03e063ac7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1610 @@ -0,0 +1,2 @@ + +support of directX in windows guest diff --git a/results/classifier/accel-gemma3:12b/vmm/1610368 b/results/classifier/accel-gemma3:12b/vmm/1610368 new file mode 100644 index 000000000..a03b75e21 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1610368 @@ -0,0 +1,44 @@ + +qemu-system-x86_64 read acces DENIED in apparmor + +When starting a win8.1 VM in virt-manager I see theses errors in dmesg + +[ 185.210435] audit: type=1400 audit(1470419576.704:27): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" pid=4885 comm="apparmor_parser" +[ 185.220800] audit: type=1400 audit(1470419576.716:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4//qemu_bridge_helper" pid=4885 comm="apparmor_parser" +[ 185.356159] audit: type=1400 audit(1470419576.848:29): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:1" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356244] audit: type=1400 audit(1470419576.848:30): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:129" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356317] audit: type=1400 audit(1470419576.848:31): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:130" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356396] audit: type=1400 audit(1470419576.848:32): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:131" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356486] audit: type=1400 audit(1470419576.852:33): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:257" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356545] audit: type=1400 audit(1470419576.852:34): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:0" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 + + +the process 4912 is : + +libvirt+ 4912 1 36 19:52 ? 00:00:51 qemu-system-x86_64 -enable-kvm -name win8.1 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu Broadwell-noTSX,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d694857f-577a-45d4-81d2-4f3672ae7bd4 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win8.1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/TEMPO/VMS/win81.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:9d:db:21,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -k fr -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device usb-host,hostbus=2,hostaddr=10,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on + + +I have no visible problems with the VM but just wanted to signal this to developpers in case this is not normal behaviour. + +ProblemType: Bug +DistroRelease: Ubuntu 16.04 +Package: qemu-system-x86 1:2.5+dfsg-5ubuntu10.3 +ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 +Uname: Linux 4.4.0-31-generic x86_64 +ApportVersion: 2.20.1-0ubuntu2.1 +Architecture: amd64 +CurrentDesktop: KDE +Date: Fri Aug 5 19:57:37 2016 +InstallationDate: Installed on 2016-05-14 (83 days ago) +InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) +ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.4.0-31-generic root=UUID=54def8c1-2495-44c4-b760-f8dbc15e25b1 ro rootflags=subvol=@ quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 02/24/2016 +dmi.bios.vendor: Intel Corporation +dmi.bios.version: RYBDWi35.86A.0355.2016.0224.1501 +dmi.board.name: NUC5i5RYB +dmi.board.vendor: Intel Corporation +dmi.board.version: H40999-504 +dmi.chassis.type: 3 +dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0355.2016.0224.1501:bd02/24/2016:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-504:cvn:ct3:cvr: \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1612908 b/results/classifier/accel-gemma3:12b/vmm/1612908 new file mode 100644 index 000000000..5addf283a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1612908 @@ -0,0 +1,8 @@ + +qom-[list,tree,get,set] don't accept tcp endpoint arg + +Hi, + +I'm using origin/master [6bbbb0ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. + +I have a patch to fix this issue that I can submit to the developer list. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1613 b/results/classifier/accel-gemma3:12b/vmm/1613 new file mode 100644 index 000000000..04ea9d8a4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1613 @@ -0,0 +1,38 @@ + +Enhanced SuperSpeed Isochronous Endpoints with high-bandwidth pipes not working (Webcams and Microphones) +Description of problem: +I have encountered an issue with QEMU when forwarding HD webcams and microphones in SuperSpeed mode. + +When passing the USB webcam "Logitech BRIO Ultra HD Webcam" to the guest using USB HighSpeed mode, all pixel formats and video modes work as expected. However, when using SuperSpeed mode, only the MJPEG format operates at low resolutions. I have attached a [USB_Webcam_Testing_Truth_Table.pdf](/uploads/309d493989da1164198af0b315012fb1/USB_Webcam_Testing_Truth_Table.pdf) that displays the functioning modes. + +This issue arises with both qemu-xhci and nec-usb-xhci xHCI implementations, as well as with usb-host and usb-redir. + +Upon tracing and comparing the USB packets from the host and guest systems, I discovered an issue with the isochronous endpoint configurations supporting "high bandwidth" pipes (e.g., SS Companion Descriptor with bMaxBurst > 0). I created three pcap files to illustrate the problem: +1. [host-libusb.pcapng](/uploads/18a66948dc6dc10ff68b7f55d70fa209/host-libusb.pcapng) +2. [qemu-guest.pcapng](/uploads/b616507f2f7c1c042a9d085dc3af579f/qemu-guest.pcapng) +3. [host-native.pcapng](/uploads/279aa7f264a75a77203fa7bf6c5afc83/host-native.pcapng) + +To generate each capture, I executed the following command: +```console +timeout --preserve-status 3s ffplay -f v4l2 -i "/dev/video0" -input_format mjpeg -framerate 30 -video_size 1920x1060 +``` + +The "SET INTERFACE" packet reveals that the USB video driver selects bAlternateSetting=7, which has the following parameters: +``` +wMaxPacketSize: 1024 +bMaxBurst: 2 +bmAttributes: 0x01 + .... ..01 = Mult: 1 +``` +According to Section 4.14.2.1.3 of the xHCI specification, the size of an isoch transfer should be `Packet Size * (Max Burst Size + 1) * (Mult + 1) = 6144`. + +However, the host-libusb.pcapng capture shows that each transfer is only 1024 bytes in size. + +For higher bitrate formats, it is observed that the system generates erroneous transfers in which the data offset in the isodescriptor exceeds the packet size. + +Currently, I am unsure of the cause of this issue. If you need any additional information, logs, or specific USB packet captures, I would be more than happy to provide them. + +Thanks +Additional information: +[lsusb-cam-SuperSpeed.txt](/uploads/712ac9e67d0b53ce46573bee3df883d0/lsusb-cam-SuperSpeed.txt) +[lsusb-cam-HighSpeed.txt](/uploads/70f855e471714fb1b48a7ed7912c0be4/lsusb-cam-HighSpeed.txt) diff --git a/results/classifier/accel-gemma3:12b/vmm/1614 b/results/classifier/accel-gemma3:12b/vmm/1614 new file mode 100644 index 000000000..1d1d04f1e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1614 @@ -0,0 +1,2 @@ + +Add option to chardev pty for setting a named link to the allocated pty diff --git a/results/classifier/accel-gemma3:12b/vmm/1614521 b/results/classifier/accel-gemma3:12b/vmm/1614521 new file mode 100644 index 000000000..75c78f068 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1614521 @@ -0,0 +1,4 @@ + +-display accepts "none[a-z,0-9]*" instead of 'none' + +When using the '-display' option the parameter 'none' is not the only string that causes the behaviour of 'none'. I can use '-display noneMICKEYMOUSE' and still have the none behaviour. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1614609 b/results/classifier/accel-gemma3:12b/vmm/1614609 new file mode 100644 index 000000000..379b0cf04 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1614609 @@ -0,0 +1,47 @@ + +alphabetical order of monitor options + +Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. +It had me overlook the 'cont' option at glance. Which is just a little impractical. + +... +boot_set bootdevice -- define new values for the boot device list +change device filename [format [read-only-mode]] -- change a removable medium, optional format +chardev-add args -- add chardev +chardev-remove id -- remove chardev +client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display +closefd closefd name -- close a file descriptor previously passed via SCM rights +commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files +cpu index -- set the default CPU +cpu-add id -- add cpu +c|cont -- resume emulation +delvm tag|id -- delete a VM snapshot from its tag or id +... + +I tested this list with 'sort' just to make sure and make a point: + +$ cat Desktop/order-orig.txt +boot_set +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +c|cont +delvm +$ cat Desktop/order-orig.txt | sort +boot_set +c|cont +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +delvm +$ \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1615212 b/results/classifier/accel-gemma3:12b/vmm/1615212 new file mode 100644 index 000000000..a5c529804 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1615212 @@ -0,0 +1,4 @@ + +SDL UI switching to monitor half-broken and scrolling broken + +ctrl+alt+2 must be pressed 2 or more times for the monitor console window to appear with -sdl, the window flashes and disappears also before finally staying open \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1615823 b/results/classifier/accel-gemma3:12b/vmm/1615823 new file mode 100644 index 000000000..63ef90b5c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1615823 @@ -0,0 +1,33 @@ + +Windows 10 reports no compatible TPM found yet device manager shows it? + +Ubuntu 16.04 with stock kvm, libvirt, ovmf +Qemu 2.5 installed from stock ubuntu ppa +Qemu 2.6.1 built from tarball. +Qemu 2.7.0-rc4 built from tarball. + +Windows 10 guest reports a TPM device is installed and the driver functional under Device Manager-->Security Devices. TPM Administrator however advises no compatible TPM chip can be found. + +Qemu 2.5 is buggy and prevents the guest loading the TPM driver, this was addressed by http://git.qemu.org/?p=qemu.git;a=commit;h=2b1c2e8e5f1990f0a201a8cbf9d366fca60f4aa8 + +Have tested the below cmd out on both qemu-2.6.1 and qemu-2.7.0-rc4, both suffer the same problem. My TPM is most certainly compatible as installing Win10Pro onto the same host as bare metal provides me the desired and expected functionality aka Bitlocker and TPM Administrator work. + +sudo ./qemu-system-x86_64 \ +-enable-kvm \ +-machine q35 \ +-cpu host \ +-m 4096 \ +-smp 4,sockets=1,cores=2,threads=2 \ +-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \ +-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \ +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x2 \ +-drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/mnt/120GB_SSD/wintpm_VARS.fd,if=pflash,format=raw,unit=1 \ +-drive file=/mnt/120GB_SSD/wintpm.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \ +-drive file="/mnt/share/Filestorage/Images/Microsoft Windows 10 Pro x64.iso",format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on \ +-device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 \ +-drive file=/mnt/share/Filestorage/Images/virtio-win-0.1.117.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-1,readonly=on \ +-device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 \ +-tpmdev passthrough,id=tpm-tpm0,path=/dev/tpm0,cancel-path=/sys/class/tpm/tpm0/device/cancel \ +-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1617385 b/results/classifier/accel-gemma3:12b/vmm/1617385 new file mode 100644 index 000000000..32f3ff657 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1617385 @@ -0,0 +1,14 @@ + +No snapshot possible with virtio-gpu activated + +I'm using "Qemu" and "Virtual Machine Manager" on Debian-8-Stretch - both newest versions out of the Debian-testing-repository (state 26.08.2016). + +If I try to save a virtual machine, it fails and I'll get the following error: + +libvirtError: internal error: unable to execute QEMU command 'migrate': State blocked by non-migratable device '0000:00:02.0/virtio-gpu' + +This only happens, if I chose "Virtio" as graphics-driver (no matter if I use "Spice" or "Vnc" as Server by the way). If I switch to any other driver (Cirrus, Qxl, Vga, VMvga...) there is no problem to take a snapshot and save the virtual machine. + +Unfortunately "virtio-gpu" (together with "Spice-Server") is the only driver that provides proper working/running my virtual machines on my PC. + +feuerkogel1 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1619438 b/results/classifier/accel-gemma3:12b/vmm/1619438 new file mode 100644 index 000000000..f2845be84 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1619438 @@ -0,0 +1,4 @@ + +GTK+ UI, delete key deletes to the left in the monitor + +it must delete characters to the right, otherwise it is like having two backspaces \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1620660 b/results/classifier/accel-gemma3:12b/vmm/1620660 new file mode 100644 index 000000000..f62b52f74 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1620660 @@ -0,0 +1,8 @@ + +man page is missing suboptions for "-display" + +Some of the display options have suboptions, for example: + +> -display gtk[,grab_on_hover=on|off][,gl=on|off] + +None of these suboptions are currently documented in qemu-options.hx (checked git@f04ec5a) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1622 b/results/classifier/accel-gemma3:12b/vmm/1622 new file mode 100644 index 000000000..7ead23754 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1622 @@ -0,0 +1,2 @@ + +PNG screendump has R/B channels swapped diff --git a/results/classifier/accel-gemma3:12b/vmm/1622582 b/results/classifier/accel-gemma3:12b/vmm/1622582 new file mode 100644 index 000000000..c5665da10 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1622582 @@ -0,0 +1,37 @@ + +Can't install Windows 7 with q35 (SATA) + +I'm trying to install Windows 7 on a q35 machine on a "SATA disk". If I use q35 the installation is extremely slow. With extremely slow I mean, that the first few minutes (10-15 minutes) on the second installation step (copying files to disk) nothing happens. Than there is some progress, maybe until 9% and than there is "silence" for another 10 minutes or so. Therefore I used iotop (with --only option) in order to see, if there are any disk operations. But as I mentioned, only a few times qemu writes something to disk (with about < 1M/s). But most of the time there is nothing from qemu. Therefore the installation lasts over an hour. But even worse, after installation I can't boot Windows. Windows-Start-Manager tells me, that windows couldn't be loaded because the kernel is missing or corrupt (Status 0xc0000221, File: \Windows\system32\ntoskrnl.exe). If I use IDE on q35 or pc-i440fx-2.6 everything works fine. There is a continuous installation progress and iotop shows continuous disk writes with max 30M/s (but also 5M/s and other values...). + +I've tried qemu 2.6.0, 2.6.1 and 2.7.0 (all versions from git). + +My host machine: +Ubuntu 14.04.5 LTS +3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux +Intel(R) Core(TM) i5-3470 CPU +16 GB RAM + + +I used the following commands: + +"Standard" command +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -hda win7_qemu_standard_q35.qcow2 -cdrom win7proX64.iso -boot order=d + +I think by using -hda sata will be used?!? + +With explicit ahci: +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -drive file=win7_qemu_standard_q35.qcow2,media=disk,if=none,id=sata-disk -device ich9-ahci,id=ahci -device ide-drive,drive=sata-disk,bus=ahci.0 -drive file=win7proX64.iso,media=cdrom,if=none,id=sata-cdrom -device ide-cd,drive=sata-cdrom,bus=ahci.1 -boot order=d + +I don't know if this is totally correct, because it's a little bit weird that I have to use ide-drive on a ich9 bus. + +Without kvm there is a continious disk write with 100 K/s - 5 M/s (works only with qemu 2.7.0, otherwise I get a 0x000000D1 bluescreen on the setup start screen): +qemu-system-x86_64 -m 2048 -machine q35 -cpu IvyBridge -hda win7_qemu_standard_q35.qcow2 -cdrom win7proX64.iso -boot order=d + +But with all three commands the installed Windows is not working, because always the same error occurs: windows couldn't be loaded because kernel is missing or corrupt + +Interestingly both commands ("standard" command and with explicit ahci) works very well with a Windows 10 installation. + +In my opinion it's a "SATA problem", because if I use e.g. piix4-ide instead of ich9-ahci it works: +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -drive file=win7_qemu_standard_q35.qcow2,media=disk,if=none,id=ide-disk -device piix4-ide,id=ide -device ide-drive,drive=ide-disk,bus=ide.0 -drive file=win7proX64.iso,media=cdrom,if=none,id=ide-cdrom -device ide-cd,drive=ide-cdrom,bus=ide.1 -boot order=d + +With this command there is a continuous disk write and the installation is bootable. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1626972 b/results/classifier/accel-gemma3:12b/vmm/1626972 new file mode 100644 index 000000000..41cdf8ad9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1626972 @@ -0,0 +1,37 @@ + +QEMU memfd_create fallback mechanism change for security drivers + +And, when libvirt starts using apparmor, and creating apparmor profiles for every virtual machine created in the compute nodes, mitaka qemu (2.5 - and upstream also) uses a fallback mechanism for creating shared memory for live-migrations. This fall back mechanism, on kernels 3.13 - that don't have memfd_create() system-call, try to create files on /tmp/ directory and fails.. causing live-migration not to work. + +Trusty with kernel 3.13 + Mitaka with qemu 2.5 + apparmor capability = can't live migrate. + +From qemu 2.5, logic is on : + +void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, int *fd) +{ + if (memfd_create)... ### only works with HWE kernels + + else ### 3.13 kernels, gets blocked by apparmor + tmpdir = g_get_tmp_dir + ... + mfd = mkstemp(fname) +} + +And you can see the errors: + +From the host trying to send the virtual machine: + +2016-08-15 16:36:26.160 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Migration operation has aborted +2016-08-15 16:36:26.248 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Live Migration failure: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +From the host trying to receive the virtual machine: + +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.356794] type=1400 audit(1471289779.791:72): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12565 comm="apparmor_parser" +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.357048] type=1400 audit(1471289779.791:73): apparmor="STATUS" operation="profile_load" profile="unconfined" name="qemu_bridge_helper" pid=12565 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.877027] type=1400 audit(1471289780.311:74): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.904407] type=1400 audit(1471289780.343:75): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.973064] type=1400 audit(1471289780.407:76): apparmor="DENIED" operation="mknod" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/memfd-tNpKSj" pid=12625 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 ouid=107 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979871] type=1400 audit(1471289780.411:77): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979881] type=1400 audit(1471289780.411:78): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/var/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 + +When leaving libvirt without apparmor capabilities (thus not confining virtual machines on compute nodes, the live migration works as expected, so, clearly, apparmor is stepping into the live migration). I'm sure that virtual machines have to be confined and that this isn't the desired behaviour... \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1627 b/results/classifier/accel-gemma3:12b/vmm/1627 new file mode 100644 index 000000000..9e5eb501d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1627 @@ -0,0 +1,40 @@ + +Aarch64: VTCR.T0SZ / iasize test for Aarch32 guests wrong +Description of problem: +With QEMU 8 we are no longer able to execute Aarch32 guest code on an Aarch64 host. We use virtualization for the QEMU guest: +- The QEMU guest kernel (L4Re kernel) runs at EL2 in AArch64 mode. +- The L4Re guest code runs at EL1 in AAarch32 mode. + +It seems that the check for T0SZ / iasize in `ptw.c` / `check_s2_mmu_setup()` is too strict: +``` +if (is_aa64) { + /* + * AArch64.S2InvalidTxSZ: While we checked tsz_oob near the top of + * get_phys_addr_lpae, that used aa64_va_parameters which apply + * to aarch64. If Stage1 is aarch32, the min_txsz is larger. + * See AArch64.S2MinTxSZ, where min_tsz is 24, translated to + * inputsize is 64 - 24 = 40. + */ + if (iasize < 40 && !arm_el_is_aa64(&cpu->env, 1)) { + goto fail; + } +``` +The above test fails for us when executing Aarch32 EL1 code on Aarch64 EL2. + +Please note that the comment talks about `S2MinTxSZ` / `min_tsz`, so if the **minimum** value of `T0SZ` is 24, then the **maximum** value of `iasize` is `64-24=40` so the following comparison would be more appropriate (I replaces `<` by `>`): +``` +if (iasize > 40 && !arm_el_is_aa64(&cpu->env, 1)) { + goto fail; +} +``` +However, the minimum value of `VTCR_EL2.T0SZ` is either 16 or 12, see `VTCR_EL2.DS`: +- `VTCR_EL2.DS=0b0`: **minimum** value of `VTCR_EL2.T0SZ` is 16 => **maximum** value of `iasize` is 48, +- `VTCR_EL2.DS=0b1`: **minimum** value of `VTCR_EL2.T0SZ` is 12 => **maximum** value of `iasize` is 52. + +Regarding the minimum of `iasize` / maximum of `VTCR_EL2.T0SZ`, see `ID_AA64MMFR_EL1.ST`: +- `ID_AA64MMFR2_EL1.ST=0b0000`: **maximum** value of `VTCR_EL2.T0SZ` is 39 => **minimum** value of `iasize` is 25, +- `ID_AA64MMFR2_EL1.ST=0b0001`: **maximum** value of `VTCR_EL2.T0SZ` is 48 => **minimum** value of `iasize` is 16 (or 47/17 for 64KiB granules). + +Our system executes Aarch32 EL1 code fine on Aarch64 EL2 if I weaken the comparison. +Additional information: +Sorry for not providing a test build but I'm not sure if it's worth to provide a custom build of our L4Re system, but I will happily provide one if you insist. diff --git a/results/classifier/accel-gemma3:12b/vmm/1629 b/results/classifier/accel-gemma3:12b/vmm/1629 new file mode 100644 index 000000000..af911fe43 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1629 @@ -0,0 +1,2 @@ + +qem-img Heap Buffer Overflow diff --git a/results/classifier/accel-gemma3:12b/vmm/1631 b/results/classifier/accel-gemma3:12b/vmm/1631 new file mode 100644 index 000000000..038afe0ca --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1631 @@ -0,0 +1,18 @@ + +[8.0.0] Host MacOS 13.3.1 – does not work or works incorrectly +Description of problem: +WINXP x86 - freezes before logging in on ARM macOS 13.3.1 host + +WINXP x86 - works but slowly x86_64 macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after start on ARM macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after selecting grub boot option + +**On qemu 7.2.1 all works perfectly!!!** +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1634069 b/results/classifier/accel-gemma3:12b/vmm/1634069 new file mode 100644 index 000000000..a690ea2c6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1634069 @@ -0,0 +1,6 @@ + +Exclude keys from grab + +Feature request: pressing every time a shortcut to release grab for switching windows/desktops is pretty annoying, especially for users of tiling WMs. + +QEMU have to have a way to specify keys or shortcuts (possibly something like "everything with the specified modifier key"), which would not be intercepted. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1635 b/results/classifier/accel-gemma3:12b/vmm/1635 new file mode 100644 index 000000000..0a762119f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1635 @@ -0,0 +1,38 @@ + +Slow graphics output under aarch64 hvf (no dirty bitmap tracking) +Description of problem: +When using a display adapter such as `bochs-display` (which, yes, I realize is not the ideal choice for an aarch64 guest, but it works fine under TCG and KVM, so bear with me) under `hvf` acceleration on an M1 Mac, display output is slow enough to be measured in seconds-per-frame. + +The issue seems to stem from each write to the framebuffer memory resulting in a data abort, while the expected behavior is that only one such write results in a data abort exception, which is handled by marking the region dirty and then subsequent writes do not yield exceptions until the display management in QEMU resets the dirty flag. Instead, every pixel drawn causes the VM to trap, and performance is degraded. +Steps to reproduce: +1. Start an aarch64 HVF guest with the `bochs-display` display adapter. +2. Observe performance characteristics. +3. +Additional information: +I reported this issue on IRC around a year ago, and was provided with a patch by @agraf which I have confirmed works. That patch was shared on the `qemu-devel` mailing list in February, 2022, with a response from @pm215: https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg00609.html + +As a quick summary, the patch takes this snippet from the i386 HVF target: + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/hvf/hvf.c#L132-138 + +And applies a variation of it to the ARM target when handling a data abort exception, before this assert: + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1381 + +Something to the effect of: + +```c + if (iswrite) { + uint64_t gpa = hvf_exit->exception.physical_address; + hvf_slot *slot = hvf_find_overlap_slot(gpa, 1); + + if (slot && slot->flags & HVF_SLOT_LOG) { + memory_region_set_dirty(slot->region, 0, slot->size); + hv_vm_protect(slot->start, slot->size, HV_MEMORY_READ | + HV_MEMORY_WRITE | HV_MEMORY_EXEC); + break; + } + } +``` + +I am reporting this issue now as I updated my git checkout with the release of QEMU 8.0.0 and was surprised to find that the patch had never made it upstream and the issue persists. diff --git a/results/classifier/accel-gemma3:12b/vmm/1635695 b/results/classifier/accel-gemma3:12b/vmm/1635695 new file mode 100644 index 000000000..20e2a54d2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1635695 @@ -0,0 +1,9 @@ + +ovmf + smp + hyper-v + windows 7: doesn't work + +- using ovmf +- enable smp (>1 processors/cores) +- enable hyper-v features (eg. -cpu Haswell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff) +- try to boot or install windows 7 x64 + +Result: black screen and hangs \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1637447 b/results/classifier/accel-gemma3:12b/vmm/1637447 new file mode 100644 index 000000000..6fdaceb07 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1637447 @@ -0,0 +1,13 @@ + +VNC/RFB: QEMU reports incorrect name (length) + +If the name of a machine (as set with the -name argument) has a length longer than 1024, (RFB) VNC clients will not receive a correct RFB ServerInit message. + +I suspect this is the problem: + +https://github.com/qemu/qemu/blob/master/ui/vnc.c#L2463 + +The return value of snprintf is used as the value for the name-length field in the ServerInit message. +This is problematic for names that were truncated to 1024, as the length will now be bigger than the actual name. + +I think a quick fix would be to simply report min(size,1024) to the client... \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1638 b/results/classifier/accel-gemma3:12b/vmm/1638 new file mode 100644 index 000000000..e4bc7afbd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1638 @@ -0,0 +1,20 @@ + +BUG: Segmentation fault when -object memory-backend-file use readonly=on, prealloc=on together +Description of problem: +Segmentation Fault while booting VM. +Steps to reproduce: +1. set qemu boot params to `-object memory-backend-file,id=mem1,readonly=on,prealloc=on,mem-path=<any-img-file>,size=4G` +2. +3. +Additional information: +It might not be a bug, probably a feature. +The reason of this segfault is: +readonly would mmap the backend file using PROT_READ, make it readonly, +but the prealloc=on would touch_pages the memory mmaped by the file. +SO the segfault happens. + +But there is no docs about this segfault condition (the readonly and prealloc cannot be used together.) + +And maybe there is a way to solve this problem, I think. +Use mmap the memory backend file to PROT_READ|PROT_WRITE at the beginnning, after touch_pages, then mprotect the memory. +change the prot to readonly if required. diff --git a/results/classifier/accel-gemma3:12b/vmm/1639791 b/results/classifier/accel-gemma3:12b/vmm/1639791 new file mode 100644 index 000000000..25bb8b59b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1639791 @@ -0,0 +1,24 @@ + +early virtio console output is lost + +This is broken in git and reportedly in 2.5 through 2.7. + +Running a Linux kernel which includes a testsuite in initrd sometimes produces no output. + +Reportedly the console is sometimes not open when the early userspace tries to log output resulting in either the testsuite terminating early or not writing the output. + +Workaround patch is here: + +https://git.zx2c4.com/WireGuard/commit/?id=d2de8b0862a7fbb51a7f2f958d58f0efe4648259 + +reportedly you would get -EBADF there when no output is generated. + +Also this reportedly happens with virtio console only, not virtio serial port. + +It seems that the author of said testsuite did not report the problem so I write it down so it does not get lost. + +test (in bash): + +n=0 ; while [ $n -lt 100 ] && grep -m 1 -F "WireGuard Test Suite on Linux 4.8.6" <( /opt/qemu/bin/qemu-system-x86_64 -nodefaults -nographic -machine q35,accel=kvm -cpu host -smp 2 -m 64M -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -device virtio-serial,max_ports=2 -chardev stdio,id=stdio -device virtconsole,chardev=stdio -chardev file,id=status,path=result.txt -device virtserialport,chardev=status -monitor none -kernel wireguard-testing-harness-bzImage-e87cb2a7-145c-4985-907f-17e81fae329b -append "console=hvc0 initcall_debug=1 loglevel=7" ) ; do echo $n ; n=$(expr $n + 1) ; pkill -f wireguard ; done + +This typically does 10-20 iterations but sometimes tens of iterations run without issue. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1640 b/results/classifier/accel-gemma3:12b/vmm/1640 new file mode 100644 index 000000000..c13345f56 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1640 @@ -0,0 +1,26 @@ + +aarch64: usb_mtp_get_data: Assertion `(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed +Description of problem: +When attempting to write to an MTP device in QEMU 8.0.0 on arm64, QEMU will crash at runtime with the following error: +`qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.` + +This was observed in Nixpkgs where we use QEMU to provide automated testing of MTP devices for GVFS and jmtpfs, the full log for that test run that crashes due to this QEMU regression on arm64 is available here https://hydra.nixos.org/build/218858556/nixlog/1 +Steps to reproduce: +1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0 +2. Mount the MTP device using something like: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + dd if=/dev/urandom of=./mtpDevice/file + ``` +4. Observe that QEMU will crash when trying to write to the device, like this: + ``` + client # 10+0 records in + client # 10+0 records out + client # 10485760 bytes (10 MB, 10 MiB) copied, 0.0318363 s, 329 MB/s + client # qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.error + ``` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1640525 b/results/classifier/accel-gemma3:12b/vmm/1640525 new file mode 100644 index 000000000..ee51e503a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1640525 @@ -0,0 +1,109 @@ + +-net socket,connect/listen does not work in 2.7.0 + +Using 2.7.0 release on Debian Sid. What I did: start one VM with: +---- +/home/pierre/build/qemu/build/x86_64-softmmu/qemu-system-x86_64 \ +-smp 4 \ +-cpu Nehalem \ +-soundhw ac97 \ +-k fr \ +-localtime \ +-enable-kvm \ +-m 4099 \ +-drive file=/mnt/virtualMachines/qemu/lfs-7.10-porg.qcow2,cache=writeback \ +-cdrom /mnt/virtualMachines/qemu/grub-img.iso \ +-boot order=c,once=d,menu=on \ +-vga std \ +-serial mon:stdio \ +-net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:58 \ +-net user,vlan=0,hostfwd=tcp::2223-10.0.2.9:22 \ +-net nic,vlan=1,model=e1000,macaddr=52:54:00:12:34:56 \ +-net socket,vlan=1,listen=:4321 +---- +Start another one with: +---- +/home/pierre/build/qemu/build/x86_64-softmmu/qemu-system-x86_64 \ +-smp 4 \ +-cpu Nehalem \ +-soundhw ac97 \ +-k fr \ +-localtime \ +-enable-kvm \ +-m 4099 \ +-drive file=/mnt/virtualMachines/qemu/lfs-7.10-october.qcow2,cache=writeback \ +-cdrom /mnt/virtualMachines/qemu/grub-img.iso \ +-boot order=c \ +-serial mon:stdio \ +-vga std \ +-net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:57 \ +-net socket,vlan=0,connect=localhost:4321 +---- +The network settings of the first machine are: +---- +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever +2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 + link/ether 52:54:00:12:34:58 brd ff:ff:ff:ff:ff:ff +3: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 + link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff +4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 + link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff + inet 10.0.2.9/24 brd 10.0.2.255 scope global br0 + valid_lft forever preferred_lft forever +---- +The network settings on the second machine are: +---- +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever +2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 + link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff + inet 10.0.2.10/24 brd 10.0.2.255 scope global enp0s3 + valid_lft forever preferred_lft forever +---- +typing "ping -c 1 10.0.2.10" on the first machine returns: +---- +PING 10.0.2.10 (10.0.2.10): 56 data bytes +92 bytes from virtuallfs (10.0.2.9): Destination Host Unreachable +--- 10.0.2.10 ping statistics --- +1 packets transmitted, 0 packets received, 100% packet loss +---- +and something similar when typing "ping -c 1 10.0.2.9" on the second machine. + +This very same setting works as expected in version 2.6.0. I could bisect, and the offending commit is 16a3df403b1: +---- +commit 16a3df403b10c4ac347159e39005fd520b2648bb +Author: Zhang Chen <email address hidden> +Date: Fri May 13 15:35:19 2016 +0800 + + net/net: Add SocketReadState for reuse codes + + This function is from net/socket.c, move it to net.c and net.h. + Add SocketReadState to make others reuse net_fill_rstate(). + suggestion from jason. + + v4: + - move 'rs->finalize = finalize' to rs_init() + + v3: + - remove SocketReadState init callback + - put finalize callback to net_fill_rstate() + + v2: + - rename ReadState to SocketReadState + - add SocketReadState init and finalize callback + + v1: + - init patch + + Signed-off-by: Zhang Chen <email address hidden> + Signed-off-by: Li Zhijian <email address hidden> + Signed-off-by: Wen Congyang <email address hidden> + Signed-off-by: Jason Wang <email address hidden> +---- + +BTW, the systems on both VM are built from http://www.linuxfromscratch.org. But I do not think this is important, since I could do the bisect. Of course, I'll be happy to try other VMs, if you point me to some. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1645 b/results/classifier/accel-gemma3:12b/vmm/1645 new file mode 100644 index 000000000..9a347a06d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1645 @@ -0,0 +1,9 @@ + +qemu error `hotplug memory" error="QMP command failed: a used vhost backend has no free memory slots left"` +Description of problem: +When I create a Qemu VM with 8 Gpus and hot-plugging memory, this will return the error QMP command failed: a used vhost backend has no free memory slots left. I read some source file https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost-user.c#L2077, and debug show u->user->memory_slots is 32, but this https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c#L62 used_memslots is bigger than u->user->memory_slots. `u->user->memory_slots` is defined 32 by https://gitlab.com/qemu-project/qemu/-/blob/master/subprojects/libvhost-user/libvhost-user.h#L37, but I also see VHOST_USER_MAX_RAM_SLOTS defined 512 under x86 architecture. Can I improve `u->user->memory_slots` by any way? +Steps to reproduce: +1.crate kata containers with 8 Gpus +2.kata containers return error +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1647 b/results/classifier/accel-gemma3:12b/vmm/1647 new file mode 100644 index 000000000..cb81e3a54 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1647 @@ -0,0 +1,13 @@ + +Potential Bug in RISCV Hypervisor Extension: Timer Interrupt Handling in QEMU v8.0.0-rc1 +Steps to reproduce: +1. Build and run a simple hypervisor on QEMU v8.0.0-rc1 with the hypervisor extension feature of RISCV. +2. Set up hideleg, henvcfg, etc., in hypervisor and run the Linux kernel. +3. Observe the issue of infinite loop caused by the pending timer interrupt. +Additional information: +Linux version: riscv_aia_v1 from github.com/avpatel/linux +OpenSBI version: Modified 1.1 + +I would greatly appreciate it if you could kindly provide some guidance. Is this behavior expected or could this be a bug? I've tried to provide a detailed analysis of my observations, but I'm not 100% certain if my understanding is correct. + +Thank you for your time and consideration. diff --git a/results/classifier/accel-gemma3:12b/vmm/1648726 b/results/classifier/accel-gemma3:12b/vmm/1648726 new file mode 100644 index 000000000..1ff27d8dc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1648726 @@ -0,0 +1,21 @@ + +[usb-host] Passthrough of UAS devices fails with Windows (10) guests + +Split off from #1579306 as this is a distinct issue. + +Physical USB storage devices that support the UAS protocol do not work correctly when passed through to Windows guests (I've only tested this with Windows 10 x64, build 1607). + +Passing through such a device results in the older BOT/MSC protocol being used: + +<See attachment win10-uas-fail.png> + +Using the same domain configuration with a Linux guest (tested with SystemRescueCD 4.8.0) works correctly: + +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + + +In both cases, the VM was launched via libvirt, which generated the following command line: + +/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1653577 b/results/classifier/accel-gemma3:12b/vmm/1653577 new file mode 100644 index 000000000..7c009f259 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1653577 @@ -0,0 +1,4 @@ + +Ability to set umask for 9pfs + +We should be able to specify the umask for 9pfs so that files created by the guest can be accessed by other users on the host. Currently they're only accessible by the user running qemu (and of course, root). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1654 b/results/classifier/accel-gemma3:12b/vmm/1654 new file mode 100644 index 000000000..77d43a005 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1654 @@ -0,0 +1,82 @@ + +Memory out of bounds access vulnerability when guest accesses Block Limits information of SCSI devices +Description of problem: +When a guest uses a Linux kernel version 5.19 or higher and uses an scsi device, there will be a memory access violation, which can be clearly seen when ASAN is turned on. + +**reason：** +Linux kernel 5.19 merge commit： + +https://github.com/torvalds/linux/commit/c92a6b5d63359dd6d2ce6ea88ecd8e31dd769f6b + +The Linux kernel will first issue a header request to obtain the VPD length before obtaining the VPD information. The BUF for obtaining the VPD length is less than 8 bytes. However, QEMU regards the header for obtaining the VPD length as obtaining all VPD information, and a memory access violation occurs when writing information to BUF. + +The specific memory out of bounds information is as follows: +==12430==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! + +==12430==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: +0x7fffebc1d000; bottom 0x7f61115ee000; size: 0x009eda62f000 (682268749824) + +False positive error reports may follow + +==12430==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200024d858 at pc 0x55767513791c bp 0x7f6111fcddc0 sp 0x7f6111fcddb0 + +WRITE of size 4 at 0x60200024d858 thread T0 + + #0 0x55767513791b in stl_he_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 + + #1 0x55767513791b in stl_be_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:464 + + #2 0x55767513791b in scsi_handle_inquiry_reply hw/scsi/scsi-generic.c:173 + + #3 0x55767513791b in scsi_read_complete hw/scsi/scsi-generic.c:318 + + #4 0x55767545d7c6 in blk_aio_complete block/block-backend.c:1425 + + #5 0x557675544d79 in coroutine_trampoline util/coroutine-ucontext.c:115 + + #6 0x7f611b9f14df (/lib/x86_64-linux-gnu/libc.so.6+0x5b4df) + +0x60200024d858 is located 4 bytes to the right of 4-byte region [0x60200024d850,0x60200024d854) + +allocated by thread T0 here: + + #0 0x557674a987f2 in malloc (/sf/bin/qemu-system-x86_64+0x7827f2) + + #1 0x7f6120141d41 in g_malloc (/usr/lib/libglib256-2.0.so.0+0x61d41) + + #2 0x557675137bb4 in scsi_send_command hw/scsi/scsi-generic.c:459 + + #3 0x55767513e902 in scsi_req_enqueue hw/scsi/scsi-bus.c:836 + + #4 0x557674c5f26e in virtio_scsi_handle_cmd_req_submit /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:589 + + #5 0x557674c5f26e in virtio_scsi_handle_cmd_vq /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:634 + + #6 0x557674c61089 in virtio_scsi_data_plane_handle_cmd /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi-dataplane.c:60 + + #7 0x557674c9a520 in virtio_queue_notify_aio_vq /root/hci/qemu/qemu-5.0.0/hw/virtio/virtio.c:2338 + + #8 0x55767552c7c4 in aio_dispatch_handler util/aio-posix.c:328 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 stl_he_p +Steps to reproduce: +1. QEMU Enable ASAN +2. Use a guest with a Linux kernel version greater than 5.19 and mount an scsi physical device +3. Upon startup, memory out of bounds access can be detected +Additional information: +At present, I have made some simple modifications, but I am not sure if this is the best solution and can serve as a reference. + +Make a judgment on buflen, ignore the header information issued by the Linux kernel, and write the VPD information when issuing the actual instruction to obtain VPD information. + +hw/scsi/scsi-generic.c:scsi_handle_inquiry_reply + +``` +if (r->buflen >= 12) { + stl_be_p(&r->buf[8], max_transfer); +} +if (r->buflen >= 16){ + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); +} +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1655764 b/results/classifier/accel-gemma3:12b/vmm/1655764 new file mode 100644 index 000000000..1d308e951 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1655764 @@ -0,0 +1,6 @@ + +qemu-img convert -c compression can't decompress + +Used -c compression option of qemu-img convert to compress qcow2, +then libvirt mount for compressed image don't work as well as decompression also +not working, tried glib-deflate to decompress \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1656 b/results/classifier/accel-gemma3:12b/vmm/1656 new file mode 100644 index 000000000..8107d5dcc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1656 @@ -0,0 +1,8 @@ + +https://wiki.qemu.org/: TLS certificate has expired (`May 14 21:15:57 2023 GMT`) +Description of problem: +The ceritficate for https://wiki.qemu.org/ has expired on May 14 21:15:57 2023 GMT. +Steps to reproduce: +1. Browse https://wiki.qemu.org/ +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1656711 b/results/classifier/accel-gemma3:12b/vmm/1656711 new file mode 100644 index 000000000..e943ce9fb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1656711 @@ -0,0 +1,16 @@ + +GTK3 interface doesn't zoom-to-fit by default + +The SDL interface automatically scales the video output to +match the window size. The GTK3 interface has an off-by-default option +"Zoom To Fit" for that. As far as I can tell, no command-line option +exists to turn that option on. That makes it harder to quickly zoom a +freshly launched VM; instead of just hitting a maximize-window hotkey, I +also have to navigate through the menu to select "Zoom To Fit". + +Given that VMs typically start out running in a much lower-resolution +video mode than the host (and VMs not running a full graphical +environment often stay that way), this seriously impacts the usability +of qemu-system. + +(Observed in QEMU 2.8) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1657841 b/results/classifier/accel-gemma3:12b/vmm/1657841 new file mode 100644 index 000000000..3239e30a3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1657841 @@ -0,0 +1,12 @@ + +QEMU Intel HAX Windows + +Hi, + +Using the latest exe's from http://qemu.weilnetz.de/w32/ + +C:\Users\therock247uk\Desktop\jan\qemu-w64-setup-20170113>qemu-system-i386 --enable-hax -m 512 -cdrom C:\Users\therock247uk\Desktop\jan\en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso +HAX is working and emulator runs in fast virt mode. +Failed to allocate 20000000 memory + +The emulator seems to hang/get stuck during booting from the CD taking out --enable-hax allows it to boot. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1659267 b/results/classifier/accel-gemma3:12b/vmm/1659267 new file mode 100644 index 000000000..579f173c0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1659267 @@ -0,0 +1,10 @@ + +It's not possible to start a VM with a network cable unplugged + +There should be a command line (sub)option to unplug a network cable. +While from the monitor interface I can issue: + +set_link virtio-net-pci.0 off + +There's no way to fire a VM from command line with that cable already unplugged. +As an example, virtualbox can do it. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1663079 b/results/classifier/accel-gemma3:12b/vmm/1663079 new file mode 100644 index 000000000..84a5fc291 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1663079 @@ -0,0 +1,23 @@ + +socket network not working + +The socket network type is no longer working in 2.8.0. + +When trying to establish a network between 2 qemu instances: + +The listening host: +qemu-system-x86_64 -netdev socket,id=in0,listen=127.0.0.1:9999 -device virtio-net-pci,netdev=in0 + +works fine, but for the second one: + +qemu-system-x86_64 -netdev socket,id=in0,connect=127.0.0.1:9999 -device virtio-net-pci,netdev=in0 + +It fails with: + +qemu-system-x86_64: -device virtio-net-pci,netdev=in0: Property 'virtio-net-device.netdev' can't find value 'in0' + +netstat shows a new connection to port 9999 in time_wait state every time. + +host: kernel 4.4.38, 64bits. + +It was working fine with previous version. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1664 b/results/classifier/accel-gemma3:12b/vmm/1664 new file mode 100644 index 000000000..878ed71a8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1664 @@ -0,0 +1,2 @@ + +mingw64 cross compile: libslirp from subproject fails to link, undefined reference to WinMain diff --git a/results/classifier/accel-gemma3:12b/vmm/1665791 b/results/classifier/accel-gemma3:12b/vmm/1665791 new file mode 100644 index 000000000..7251150c4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1665791 @@ -0,0 +1,4 @@ + +Multiple displays each attached to a separate vnc connection + +Would it be possible to create two displays in qemu (for windows 10) with each accessible by a separate vnc connection? I think this already exists for spice (and I would like it because vnc works better for me than does spice) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1668273 b/results/classifier/accel-gemma3:12b/vmm/1668273 new file mode 100644 index 000000000..8fda6a39d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1668273 @@ -0,0 +1,65 @@ + +DoS possible on - a QEMU process using userspace SLIRP? + +Steps to reproduce: + +- Launch a VM using QEMU: + +$ qemu-system-x86_64 -machine accel=kvm \ + -hda Fedora-Cloud-Base-25-1.3.x86_64.qcow2 \ + -m 2G \ + -smp 2 \ + -vnc :8 \ + -boot dc \ + -vga std \ + -cpu host \ + -net nic,vlan=0 \ + -net user,vlan=0,hostfwd=tcp::10024-:22,hostfwd=tcp::8082-:80 + +- SSH into the VM, install httpd, start httpd + +$ ssh -p 10024 root@localhost 'dnf install -y httpd && systemctl start httpd' + +- Compile and run the following Java program: + +$ cat <<EOF > URLConnectionReader.java +import java.net.*; +import java.io.*; + +public class URLConnectionReader { + public static void main(String[] args) throws Exception { + int i = 0; + while (i < 1024) { + URL this_is_404 = new URL("http://localhost:8082/blah"); + URLConnection yc = this_is_404.openConnection(); + try { + BufferedReader in = new BufferedReader(new InputStreamReader( + yc.getInputStream())); + String inputLine; + while ((inputLine = in.readLine()) != null) + System.out.println(inputLine); + in.close(); + } catch (Exception e) { + //HttpURLConnection urlConnection = (HttpURLConnection) yc; + //urlConnection.disconnect(); + } + i++; + } + Thread.sleep(1000000000); + } +} + +$ javac URLConnectionReader.java + +$ java URLConnectionReader & + +The java program tries to open a lot of HTTP connections, but never calls disconnect() on any. + +- Take a look at the list of open FDs of the qemu process: + +$ ls -tl /proc/${qemu-pid}/fd + +$ lsof -p ${qemu-pid} +All of the TCP connections will be stuck at FIN_WAIT2 + +The VM becomes unresponsive. Neither SSH or VNC works on this. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1668556 b/results/classifier/accel-gemma3:12b/vmm/1668556 new file mode 100644 index 000000000..bd1f8baf6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1668556 @@ -0,0 +1,20 @@ + +QEMU Guest Agent service fails to start on Windows 10 RS2 preview + +The "QEMU Guest Agent" service cannot be started on Windows 10 RS2 preview build. After starting the service this error message is displayed: "Windows could not start QEMU Guest Agent service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion." + +Output from the Windows System event log: +<?xml version="1.0" encoding="utf-8" standalone="yes"?> +<Events><Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Service Control Manager' Guid='{555908d1-a6d7-4695-8e1e-26931d2012f4}' EventSourceName='Service Control Manager'/><EventID Qualifiers='49152'>7009</EventID><Version>0</Version><Level>2</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8080000000000000</Keywords><TimeCreated SystemTime='2017-02-28T09:39:35.713939500Z'/><EventRecordID>1406</EventRecordID><Correlation/><Execution ProcessID='568' ThreadID='964'/><Channel>System</Channel><Computer>LT-WIN10-64</Computer><Security/></System><EventData><Data Name='param1'>30000</Data><Data Name='param2'>QEMU Guest Agent</Data><Binary>510045004D0055002D00470041000000</Binary></EventData></Event></Events> + +The "QEMU Guest Agent VSS Provider" service is running successfully. + +It worked on Windows 10 RS1 (before the upgrade). + +QEMU Guest Agent version: +Installed from virtio-win-0.1.126_amd64 +which was built from master branch with latest commit (8aaf403) - https://github.com/virtio-win/kvm-guest-drivers-windows + +Windows version (upgraded from RS1): +Windows 10 Enterprise Insider Preview +Evaluation copy. Build 15019.rs_prerelease.170121-1513 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1670377 b/results/classifier/accel-gemma3:12b/vmm/1670377 new file mode 100644 index 000000000..96b13a672 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1670377 @@ -0,0 +1,38 @@ + + VNC: short read for zlre data/RDR EndOfStream + +In openQA we have a custom VNC client (https://github.com/os-autoinst/os-autoinst/tree/master/consoles), which connects to QEMU guest and from there performs actions (sends keys, handles pointer, ...). We have several backends (https://github.com/os-autoinst/os-autoinst/tree/master/backend). With qemu backend we start QEMU guest *locally* on openQA worker which connects to it via VNC and sends commands. That works fine. + +However, with svirt backend we start QEMU on a KVM or Xen host and then connect to it remotely from openQA worker - the guest and worker are different systems. In this scenario fairly often happens that while system operates in Grub2, QEMU stops sending data via VNC: + +... +15:24:15.5341 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:50 called testapi::send_key +15:24:15.5342 27074 <<< testapi::send_key(key='c') +15:24:15.7361 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:51 called testapi::type_string +15:24:15.7362 27074 <<< testapi::type_string(string='gfxmode=1024x768; terminal_output console; terminal_output gfxterm +', max_interval=250, wait_screen_changes=0) +15:24:22.2243 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:53 called testapi::send_key +15:24:22.2244 27074 <<< testapi::send_key(key='esc') +15:24:22.4255 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:79 called testapi::send_key +15:24:22.4256 27074 <<< testapi::send_key(key='e') +15:24:22.6264 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.6265 27074 <<< testapi::send_key(key='down') +15:24:22.8273 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.8274 27074 <<< testapi::send_key(key='down') +15:24:23.0282 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:23.0283 27074 <<< testapi::send_key(key='down') +DIE short read for zlre data 107132 - 995002 at /usr/lib/os-autoinst/consoles/VNC.pm line 978. + + at /usr/lib/os-autoinst/backend/baseclass.pm line 73. +... + +My observation is that it happens only while in Grub, when resolution happened a short while ago. See attached video and log. + +Prior to QEMU 2.8.0 I was able to reproduce a similar issue with vncviewer. I started QEMU with SLES JeOS image pressed several times a 'down' key in Grub and vncviewer (Tiger VNC 1.6.0 from openSUSE Leap 42.2) crashed with rdr::EndOfStream exception. This does not happen with QEMU 2.8.0, but I am still able to reproduce similar issue via openQA. + +/usr/bin/qemu-system-x86_64 -name guest=openQA-SUT-20,debug-threads=on -S -machine pc-i440fx-2.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 87535fc1-e693-41b9-813e-834d6fc4cb5a -no-user-config -nodefaults -rtc base=utc -no-reboot -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/openQA-SUT-20.img,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:12:34:56,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-tablet-pci,id=input0,bus=pci.0,addr=0x6 -device virtio-keyboard-pci,id=input1,bus=pci.0,addr=0x7 -vnc 0.0.0.0:20,share=force-shared -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on -monitor stdio + +Host: openSUSE Leap 42.2 x86_64 KVM or Xen on x86_64 Intel with QEMU 2.6.0. +Guest: Leap 42.2. + +I can't reproduce the problem with QEMU 2.5.0, but I can with any QEMU version from 2.6 RC1 on. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1673957 b/results/classifier/accel-gemma3:12b/vmm/1673957 new file mode 100644 index 000000000..13031a0d2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1673957 @@ -0,0 +1,18 @@ + +virtfs: mapped-xattr on mount point + +With + -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2" +in the qemu command line, + shared2 on /mnt/testbis type 9p (rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144) +in the guest mount points, and + tmpfs on /tmp type tmpfs (rw,nosuid,nodev) +in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep /proc/config.gz), running qemu as user "vm-test", trying to "touch a" in /mnt/testbis on the VM fails with "Operation not supported". In addition, no file or directory actually present in the host's /tmp can be seen in the guest's /mnt/testbis. + +When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa owned by root:root, still running qemu as vm-test, trying to run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading directory '.': Cannot allocate memory", while the directory is empty. + +After a "chown vm-test /tmp/aaa", the guest can list the files (despite the permissions already allowing it to do so before), but still not write new files: "cannot touch 'b': Operation not supported". + +Do you have a pointer as to what is happening? + +PS: complete setup is running all this inside a qemu VM that I use for testing, I guess it shouldn't matter but saying it just in case \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1677 b/results/classifier/accel-gemma3:12b/vmm/1677 new file mode 100644 index 000000000..2d290dab0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1677 @@ -0,0 +1,14 @@ + +qemu-system-x86_64 cannot run on Windows when -smp is specified with a value higher than `1`. An important argument for any expectation of VM performance +Description of problem: +qemu-system-x86_64 seems to crash on Windows the moment you try to use -smp to define more vcpus, even the basic usage of `-smp 4` will cause qemu to segfault after the guest's boot option is selected. +Steps to reproduce: +1. `qemu-system-x86_64 -smp 4 -cdrom rhel-9.2-x86_64-dvd.iso -drive if=pflash,format=raw,unit=0,readonly=on,file=edk2-x64/OVMF_CODE.fd -m 6G -nodefaults -serial mon:stdio` +2. Select the boot option to begin your installation +3. qemu hangs for 10 or so seconds then throws a Segmentation Fault. +Additional information: +1. This does not happen if -smp arguments are omitted, but running VMs with a single vcpu thread is slow and painful. +2. This still happens even without OVMF (Traditional bios booting) +3. This still happens even without -defaults and without a serial device + +Only output from qemu at death is `Segmentation fault` diff --git a/results/classifier/accel-gemma3:12b/vmm/1677492 b/results/classifier/accel-gemma3:12b/vmm/1677492 new file mode 100644 index 000000000..3b2ddbe18 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1677492 @@ -0,0 +1,11 @@ + +block_set_io_throttle complaints Need exactly one of 'device' and 'id' + +All of sudden, after a qemu update, block_set_io_throttle does not work anymore. + +Full command to QEMU monitor -- + +(qemu) block_set_io_throttle db 0 0 0 0 0 0 +Need exactly one of 'device' and 'id' + +The help text still point to the same old syntax, which no longer works. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1678466 b/results/classifier/accel-gemma3:12b/vmm/1678466 new file mode 100644 index 000000000..e59da9335 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1678466 @@ -0,0 +1,47 @@ + +using x-vga=on with vfio-pci leads to segfault + +bug occures at least with qemu 2.8.0 and 2.8.1 in 64bit-system + +stripped cmd for minimal config: +qemu-system-i386 -m 2048 -M q35 -enable-kvm -nodefaults -nodefconfig -device ioh3420,bus=pcie.0,addr=0x9,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=01.0,x-vga=on + +Backtrace is: +#0 0x00005555557ca836 in memory_region_update_container_subregions (subregion=0x55555828f2f0) at qemu-2.8.1/memory.c:2030 +#1 0x00005555557ca9dc in memory_region_add_subregion_common (mr=0x0, offset=8, subregion=0x55555828f2f0) at qemu-2.8.1/memory.c:2049 +#2 0x00005555557caa9a in memory_region_add_subregion_overlap (mr=0x0, offset=8, subregion=0x55555828f2f0, priority=1) at qemu-2.8.1/memory.c:2066 +#3 0x0000555555832e48 in vfio_probe_nvidia_bar5_quirk (vdev=0x55555805aef0, nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:689 +#4 0x0000555555835433 in vfio_bar_quirk_setup (vdev=0x55555805aef0, nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:1652 +#5 0x000055555582f122 in vfio_realize (pdev=0x55555805aef0, errp=0x7fffffffdc78) at qemu-2.8.1/hw/vfio/pci.c:2777 +#6 0x0000555555a86195 in pci_qdev_realize (qdev=0x55555805aef0, errp=0x7fffffffdcf0) at hw/pci/pci.c:1966 +#7 0x00005555559be7b7 in device_set_realized (obj=0x55555805aef0, value=true, errp=0x7fffffffdeb0) at hw/core/qdev.c:918 +#8 0x0000555555bb017f in property_set_bool (obj=0x55555805aef0, v=0x55555805ced0, name=0x555556071b56 "realized", opaque=0x555557f15860, errp=0x7fffffffdeb0) at qom/object.c:1854 +#9 0x0000555555bae2e6 in object_property_set (obj=0x55555805aef0, v=0x55555805ced0, name=0x555556071b56 "realized", errp=0x7fffffffdeb0) at qom/object.c:1088 +#10 0x0000555555bb184f in object_property_set_qobject (obj=0x55555805aef0, value=0x55555805cd70, name=0x555556071b56 "realized", errp=0x7fffffffdeb0) at qom/qom-qobject.c:27 +#11 0x0000555555bae637 in object_property_set_bool (obj=0x55555805aef0, value=true, name=0x555556071b56 "realized", errp=0x7fffffffdeb0) at qom/object.c:1157 +#12 0x00005555558fee4b in qdev_device_add (opts=0x555556b15160, errp=0x7fffffffdf28) at qdev-monitor.c:623 +#13 0x00005555559142c1 in device_init_func (opaque=0x0, opts=0x555556b15160, errp=0x0) at vl.c:2373 +#14 0x0000555555cc3bb7 in qemu_opts_foreach (list=0x555556548b80 <qemu_device_opts>, func=0x555555914283 <device_init_func>, opaque=0x0, errp=0x0) at util/qemu-option.c:1116 +#15 0x00005555559198aa in main (argc=12, argv=0x7fffffffe388, envp=0x7fffffffe3f0) at vl.c:4574 + +as I can see, it happens during initialization of the device-option. + +seems that the code tries to loop over a memory-region mr, which is null from at least three calls before it crashes. + +because there seems to be special handling for nvidia-cards, here're the pci-infos of the card: +01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 7300 GS] [10de:01df] (rev a1) (prog-if 00 [VGA controller]) + Subsystem: Gigabyte Technology Co., Ltd Device [1458:342a] + Flags: fast devsel, IRQ 16 + Memory at de000000 (32-bit, non-prefetchable) [disabled] [size=16M] + Memory at c0000000 (64-bit, prefetchable) [disabled] [size=256M] + Memory at dd000000 (64-bit, non-prefetchable) [disabled] [size=16M] + Expansion ROM at df000000 [disabled] [size=128K] + Capabilities: [60] Power Management version 2 + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [78] Express Endpoint, MSI 00 + Capabilities: [100] Virtual Channel + Capabilities: [128] Power Budgeting <?> + Kernel driver in use: vfio-pci + +at least with a similar card in another slot the crash does not occure. +(sorry, can't change the slots at the moment) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1679126 b/results/classifier/accel-gemma3:12b/vmm/1679126 new file mode 100644 index 000000000..6bacb2ed6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1679126 @@ -0,0 +1,39 @@ + +null pointer access on migration resume of systemrescuecd boot menu with qxl-vga + +With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when resuming from a migration state file created from a VM suspended while showing the System Rescue CD 4.9.2 boot menu and using the QXL VGA device, I get a null point access in pixman_image_get_data called from qemu_spice_create_update (spice-display.c:215). When I added assert(ssd->mirror != NULL) above that line, assert failed. I don't get the crash when using standard VGA or cirrus-vga. I am using gcc-4.9.3 on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel: 4.9.15-gentoo. + +Here is the valgrind trace from the git version: +==2634== Thread 1: +==2634== Invalid read of size 4 +==3516== at 0x65F3050: pixman_image_get_data (in /usr/lib64/libpixman-1.so.0.34.0) +==3516== by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215) +==3516== by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502) +==3516== by 0x58CF77: display_refresh (qxl.c:1948) +==3516== by 0x6E8084: do_safe_dpy_refresh (console.c:1591) +==3516== by 0x6E80D5: dpy_refresh (console.c:1604) +==3516== by 0x6E4508: gui_update (console.c:201) +==3516== by 0x81898E: timerlist_run_timers (qemu-timer.c:536) +==3516== by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547) +==3516== by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662) +==3516== by 0x81952A: main_loop_wait (main-loop.c:514) +==3516== by 0x4ADD29: main_loop (vl.c:1898) + +Minimal steps to reproduce: + +Compile (debug compile flags are just so valgrind works, the crash occurs with non-debug compile flags as well): +CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --target-list=i386-softmmu,x86_64-softmmu +./configure +make + +Start VM and leave it on the System Rescue CD graphical boot menu: +x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor unix:monitor.sock,server,nowait -display gtk + +Suspend VM and save state: +socat - unix:monitor.sock + stop + migrate "exec:cat > vm.state" + quit + +Attempt to resume VM (but this crashes): +x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor unix:monitor.sock,server,nowait -display gtk -incoming exec:"cat vm.state" \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1683084 b/results/classifier/accel-gemma3:12b/vmm/1683084 new file mode 100644 index 000000000..fc479d0f9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1683084 @@ -0,0 +1,12 @@ + +DNS server not working in QEMU usermode networking + +Nslookup is returning "unknown host". +I try to ping 10.0.2.3 and it fails. Pinging 10.0.2.2 and 10.0.2.15 works correctly. +Downloading files via wget using a static IP works well. + +Results of qemu monitor command "info network" included as an attachment. + +This bug was reported as a question on stack overflow: http://stackoverflow.com/questions/43308310/dns-server-not-working-in-qemu-usermode-networking. + +This bug exists on 2.8.0 and 2.9-rc3. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1685 b/results/classifier/accel-gemma3:12b/vmm/1685 new file mode 100644 index 000000000..a882d1fe0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1685 @@ -0,0 +1,60 @@ + +QEMU segfaults when I restart Windows 11 VM with virtio-vga-gl +Description of problem: +When I restart the Windows 11 VM with the virtio GPU DoD driver installed, QEMU crashes with a SIGSEGV. This also happens if I try to uninstall this driver in the Device Manager. I attached the backtrace. +Steps to reproduce: +1. Install Windows 11 into the VM; +2. Install virtio GPU DoD driver; +3. Click Start -> Power -> Restart. +Additional information: +virtio-win version: 0.1.229 + +Backtrace: +``` +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff64a3e80 (LWP 118206)] +_mesa_TexParameteri () at ../mesa-23.1.1/src/mesa/main/texparam.c:1248 +1248 texObj = _mesa_get_texobj_by_target_and_texunit(ctx, target, +(gdb) bt +#0 _mesa_TexParameteri() () at ../mesa-23.1.1/src/mesa/main/texparam.c:1248 +#1 0x00007ffece03cba2 in _mesa_unmarshal_TexParameteri () at src/mapi/glapi/gen/marshal_generated0.c:5332 +#2 0x00007ffecdf1bb30 in glthread_unmarshal_batch() () at ../mesa-23.1.1/src/mesa/main/glthread.c:122 +#3 0x00007ffecdf269c2 in _mesa_glthread_finish () at ../mesa-23.1.1/src/mesa/main/glthread.c:382 +#4 _mesa_glthread_finish() () at ../mesa-23.1.1/src/mesa/main/glthread.c:347 +#5 0x00007ffecdebd20f in dri_make_current () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_context.c:303 +#6 dri_make_current () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_context.c:287 +#7 driBindContext() () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_util.c:701 +#8 0x00007ffee6e8693f in dri3_bind_context () at ../mesa-23.1.1/src/glx/dri3_glx.c:181 +#9 0x00007ffee6e78075 in MakeContextCurrent () at ../mesa-23.1.1/src/glx/glxcurrent.c:149 +#10 0x00007ffee7c84e73 in InternalMakeCurrentVendor + (dpy=dpy@entry=0x5555570fe3b0, draw=draw@entry=90177544, read=read@entry=90177544, ctxInfo=ctxInfo@entry=0x5555579418b0, callerOpcode=callerOpcode@entry=5 '\005', threadState=threadState@entry=0x55555702fbe0, vendor=0x55555707f520) at ../libglvnd-v1.6.0/src/GLX/libglx.c:871 +#11 0x00007ffee7c8bce1 in CommonMakeCurrent (dpy=0x5555570fe3b0, draw=90177544, read=90177544, context=0x55555780f760, callerOpcode=<optimized out>) + at ../libglvnd-v1.6.0/src/GLX/libglx.c:1053 +#12 0x00007ffff51f90b1 in X11_GL_MakeCurrent (_this=0x5555570c1aa0, window=<optimized out>, context=0x55555780f760) + at /usr/src/debug/sdl2/SDL2-2.26.5/src/video/x11/SDL_x11opengl.c:865 +#13 0x00007ffff51d0a3f in SDL_GL_MakeCurrent_REAL (window=0x5555570048b0, ctx=0x55555780f760) at /usr/src/debug/sdl2/SDL2-2.26.5/src/video/SDL_video.c:4120 +#14 0x00007ffff6492b86 in sdl2_gl_switch () at ../qemu-8.0.2/ui/sdl2-gl.c:83 +#15 0x000055555598efe2 in displaychangelistener_gfx_switch () at ../qemu-8.0.2/ui/console.c:1158 +#16 0x00005555559997aa in dpy_gfx_replace_surface () at ../qemu-8.0.2/ui/console.c:1815 +#17 0x0000555555d03398 in vga_draw_graphic () at ../qemu-8.0.2/hw/display/vga.c:1589 +#18 vga_update_display () at ../qemu-8.0.2/hw/display/vga.c:1789 +#19 vga_update_display () at ../qemu-8.0.2/hw/display/vga.c:1762 +#20 0x0000555555998acb in graphic_hw_update () at ../qemu-8.0.2/ui/console.c:234 +#21 0x00007ffff6493952 in sdl2_gl_refresh () at ../qemu-8.0.2/ui/sdl2-gl.c:113 +#22 0x000055555599d79a in dpy_refresh () at ../qemu-8.0.2/ui/console.c:1852 +#23 gui_update () at ../qemu-8.0.2/ui/console.c:169 +#24 0x0000555555fd9690 in timerlist_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:576 +#25 0x0000555555fd97b4 in timerlist_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:509 +#26 qemu_clock_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:590 +#27 qemu_clock_run_all_timers () at ../qemu-8.0.2/util/qemu-timer.c:672 +#28 0x0000555555fd9a53 in main_loop_wait () at ../qemu-8.0.2/util/main-loop.c:603 +#29 0x0000555555e1ab17 in qemu_main_loop () at ../qemu-8.0.2/softmmu/runstate.c:731 +--Type <RET> for more, q to quit, c to continue without paging--c +#30 qemu_default_main () at ../qemu-8.0.2/softmmu/main.c:37 +#31 0x00007ffff6c15850 in __libc_start_call_main (main=main@entry=0x55555598baa0 <main>, argc=argc@entry=33, argv=argv@entry=0x7fffffffd338) + at ../sysdeps/nptl/libc_start_call_main.h:58 +#32 0x00007ffff6c1590a in __libc_start_main_impl + (main=0x55555598baa0 <main>, argc=33, argv=0x7fffffffd338, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd328) + at ../csu/libc-start.c:360 +#33 0x000055555598e6f5 in _start () +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1687 b/results/classifier/accel-gemma3:12b/vmm/1687 new file mode 100644 index 000000000..ec5c5a3ac --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1687 @@ -0,0 +1,54 @@ + +Memory leak for x86 guest on macOS ARM host +Description of problem: +QEMU is used by docker to run `x86` binaries on Apple silicon. Then using `mmap` followed by `munmap` results in a memory leak manifested by continuously growing RSS memory usage when running `mmap` and `munmap` in a loop, e.g., when running the following binary: + +``` +#include <stdio.h> +#include <unistd.h> +#include <sys/mman.h> + +const int page = 4096; + +int work(int N) { + int *ptr = mmap(NULL, N * sizeof(int), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); + + if (ptr == MAP_FAILED) { + printf("Mapping Failed\n"); + return 1; + } + + for(int i = 0; i < N; i++) { + ptr[i] = i * 10; + } + + int err = munmap(ptr, N * sizeof(int)); + if (err != 0) { + printf("UnMapping Failed\n"); + return 1; + } + + return 0; +} + +int main() { + int N = page * 1024; + + while (1) { + int res = work(N); + if (res) { + return res; + } + printf(".\n"); + } + + return 0; +} +``` +Steps to reproduce: +``` +$ LEAK=$(docker run --platform linux/amd64 -d -it martin2718/mmap-leak ./a.out) +$ docker exec -it $LEAK top # you should observe that RES for a.out keeps growing +$ docker exec -it $LEAK pmap -x 1 # you should see a single memory mapping whose RSS memory usage keeps growing +$ docker kill $LEAK # abort the experiment +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1687270 b/results/classifier/accel-gemma3:12b/vmm/1687270 new file mode 100644 index 000000000..1dfc13822 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1687270 @@ -0,0 +1,12 @@ + +Can't write to 9p shared folder with qemu 2.9.0 + +When running a virtual machine with qemu 2.9.0 with this parameter for sharing a folder: + +-virtfs local,id=fsdev1,path=$HOME/git,security_model=none,mount_tag=git + +then the folder is shared to the VM but in some subfolders I can't delete files. The guest system then reports that the file, I want to delete, is "no file or folder". + +I've downgraded to 2.8.0 now, which re-enables deleting my files. + +Is this a known bug which will be fixed with a future version? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1687569 b/results/classifier/accel-gemma3:12b/vmm/1687569 new file mode 100644 index 000000000..331a3a6d9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1687569 @@ -0,0 +1,58 @@ + +when migration cancel, qemu main thread hung + +qemu version:v2.9.0-rc5 release + +1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-all qemu+ssh://10.59.163.38/system +2.press Ctrl+C cancel migrate + + qemu main thread hung + +(gdb) bt +#0 0x00007fca9f4574b7 in ppoll () from /lib64/libc.so.6 +#1 0x0000000000944970 in qemu_poll_ns (fds=0x293e6e0, nfds=1, timeout=-1) at util/qemu-timer.c:322 +#2 0x0000000000947e16 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:622 +#3 0x00000000008b6094 in nbd_teardown_connection (bs=0x29ccdc0) at block/nbd-client.c:59 +#4 0x00000000008b6df1 in nbd_client_close (bs=0x29ccdc0) at block/nbd-client.c:377 +#5 0x00000000008b5988 in nbd_close (bs=0x29ccdc0) at block/nbd.c:488 +#6 0x00000000008435de in bdrv_close (bs=0x29ccdc0) at block.c:2919 +#7 0x0000000000843c86 in bdrv_delete (bs=0x29ccdc0) at block.c:3100 +#8 0x000000000084620b in bdrv_unref (bs=0x29ccdc0) at block.c:4087 +#9 0x00000000008411d1 in bdrv_root_unref_child (child=0x30e4800) at block.c:1891 +#10 0x000000000084128a in bdrv_unref_child (parent=0x29c0660, child=0x30e4800) at block.c:1915 +#11 0x000000000084362a in bdrv_close (bs=0x29c0660) at block.c:2925 +#12 0x0000000000843c86 in bdrv_delete (bs=0x29c0660) at block.c:3100 +#13 0x000000000084620b in bdrv_unref (bs=0x29c0660) at block.c:4087 +#14 0x00000000008411d1 in bdrv_root_unref_child (child=0x3013910) at block.c:1891 +#15 0x0000000000848149 in block_job_remove_all_bdrv (job=0x3fa7800) at blockjob.c:154 +#16 0x00000000008a8dd8 in mirror_exit (job=0x3fa7800, opaque=0x7fca90000bf0) at block/mirror.c:576 +#17 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca90000d90) at blockjob.c:794 +#18 0x00000000009420c4 in aio_bh_call (bh=0x7fca90000dc0) at util/async.c:90 +#19 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +#20 0x00000000009480d9 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:682 +#21 0x00000000008b6094 in nbd_teardown_connection (bs=0x2921350) at block/nbd-client.c:59 +#22 0x00000000008b6df1 in nbd_client_close (bs=0x2921350) at block/nbd-client.c:377 +#23 0x00000000008b5988 in nbd_close (bs=0x2921350) at block/nbd.c:488 +#24 0x00000000008435de in bdrv_close (bs=0x2921350) at block.c:2919 +#25 0x0000000000843c86 in bdrv_delete (bs=0x2921350) at block.c:3100 +#26 0x000000000084620b in bdrv_unref (bs=0x2921350) at block.c:4087 +#27 0x00000000008411d1 in bdrv_root_unref_child (child=0x390d180) at block.c:1891 +#28 0x000000000084128a in bdrv_unref_child (parent=0x4eba200, child=0x390d180) at block.c:1915 +#29 0x000000000084362a in bdrv_close (bs=0x4eba200) at block.c:2925 +#30 0x0000000000843c86 in bdrv_delete (bs=0x4eba200) at block.c:3100 +#31 0x000000000084620b in bdrv_unref (bs=0x4eba200) at block.c:4087 +#32 0x00000000008411d1 in bdrv_root_unref_child (child=0x4ebf990) at block.c:1891 +#33 0x0000000000848149 in block_job_remove_all_bdrv (job=0x4ea85b0) at blockjob.c:154 +#34 0x00000000008a8dd8 in mirror_exit (job=0x4ea85b0, opaque=0x7fca98000bf0) at block/mirror.c:576 +#35 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca980013d0) at blockjob.c:794 +#36 0x00000000009420c4 in aio_bh_call (bh=0x7fca9801e0c0) at util/async.c:90 +#37 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +---Type <return> to continue, or q <return> to quit--- +#38 0x00000000009476ae in aio_dispatch (ctx=0x291d4b0) at util/aio-posix.c:429 +#39 0x00000000009425e4 in aio_ctx_dispatch (source=0x291d4b0, callback=0, user_data=0x0) at util/async.c:261 +#40 0x00007fcaa0101f0e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#41 0x0000000000945d86 in glib_pollfds_poll () at util/main-loop.c:213 +#42 0x0000000000945ea7 in os_host_main_loop_wait (timeout=124777230) at util/main-loop.c:261 +#43 0x0000000000945f72 in main_loop_wait (nonblocking=0) at util/main-loop.c:517 +#44 0x00000000005c7794 in main_loop () at vl.c:1898 +#45 0x00000000005cec57 in main (argc=64, argv=0x7fffe7020c58, envp=0x7fffe7020e60) at vl.c:4709 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1687578 b/results/classifier/accel-gemma3:12b/vmm/1687578 new file mode 100644 index 000000000..b986b1a64 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1687578 @@ -0,0 +1,15 @@ + +when migrate vm, reboot in guest os, the guest os sometime hang + +qemu version:v2.9.0-rc5 release + +1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-inc qemu+ssh://10.59.163.38/system +2.run reboot in guest os, add reboot in /etc/rc.local +3.guest os hang sometime. + +strace output of qemu: + +ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 698000000}, NULL, 8) = 0 (Timeout) +poll([{fd=20, events=POLLOUT}], 1, 0) = 1 ([{fd=20, revents=POLLOUT|POLLHUP}]) +ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 999000000}, NULL, 8^C <unfinished ...> \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1689 b/results/classifier/accel-gemma3:12b/vmm/1689 new file mode 100644 index 000000000..dface34cc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1689 @@ -0,0 +1,12 @@ + +memory backend file unnecessarily requires write permission while it is only mapped privately +Description of problem: +One day I wanted to boot the machine with physical memory initialized with a file, in a copy-on-write style. That is why I tried out `-mem-path` and `-object memory-backend-file`. Actually `-mem-path` already works if not considering that qemu dislikes the backing file being readonly and requires it to be writeable even when only private mappings are used here. + +I sadly found out that when using memory-backend-file, and when `share=off`, if `readonly=on`, then file is `open`ed with `O_RDONLY` and mmap prot is `PROT_READ`; if `readonly=off`, then the file is `open`ed with `O_RDWR` and mmap prot is `PROT_READ|PROT_WRITE`. I want `O_RDONLY` and `PROT_READ|PROT_WRITE` but I cannot find it anywhere. + +In my opinion, expected behavior should be that if `share=off`, the file can already be opened with `O_RDONLY` no matter what prot the mmap is. That is how linux `MAP_PRIVATE` works - basically copy on write. When I only need copy on write for the content of file, why do I require write permission for it? + +Now I cannot find a setup that opens the file with `fd=open(*, O_RDONLY)` and mmap it with `mmap(*, *, PROT_READ|PROT_WRITE, MAP_PRIVATE|*, fd, *)`. + +Tell me if I misunderstood linux (for example certain file behave differently if one open with O_RDONLY and this behavior is necessary) or qemu or other posix systems where copy-on-write does not work like this. diff --git a/results/classifier/accel-gemma3:12b/vmm/1689499 b/results/classifier/accel-gemma3:12b/vmm/1689499 new file mode 100644 index 000000000..b1244eeda --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1696746 b/results/classifier/accel-gemma3:12b/vmm/1696746 new file mode 100644 index 000000000..e907729dc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1696746 @@ -0,0 +1,16 @@ + +netdev user,restrict=on prevents forwarded ports from being accessed from other systems + +I've got a guest only network and I'm wanting to access SSH on one of the guests externally. +I'm using -netdev user,id=usernet0,hostfwd=tcp::2222-:22,restrict=yes -device virtio-net-pci,netdev=usernet0 +to forward 2222 to 22 in the guest. + +The docs state: +restrict=on|off + + If this option is enabled, the guest will be isolated, i.e. it will not be able to contact the host and no guest IP packets will be routed over the host to the outside. This option does not affect any explicitly set forwarding rules. + + +However, with restrict=on, the forwarded port is only accessible from the host. Other systems receive no data. + +This was tested with qemu 2.8. Changelog for 2.9 doesn't mention any (relevant) user networking changes, so that should also fail. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/170 b/results/classifier/accel-gemma3:12b/vmm/170 new file mode 100644 index 000000000..76efcdf1b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/170 @@ -0,0 +1,2 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server diff --git a/results/classifier/accel-gemma3:12b/vmm/1703147 b/results/classifier/accel-gemma3:12b/vmm/1703147 new file mode 100644 index 000000000..156fdba1a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1703147 @@ -0,0 +1,9 @@ + +Xfer:features:read truncating xml sent to gdb frontends + +Around line 1326 in gdbstub.c: + + if (len > (MAX_PACKET_LENGTH - 5) / 2) + len = (MAX_PACKET_LENGTH - 5) / 2; + +is truncating processor reg description xml files longer than 2045 bytes. Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1703795 b/results/classifier/accel-gemma3:12b/vmm/1703795 new file mode 100644 index 000000000..3b385128f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1703795 @@ -0,0 +1,6 @@ + +Unable to release mouse in SDL2 mode + +Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. + +This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1704186 b/results/classifier/accel-gemma3:12b/vmm/1704186 new file mode 100644 index 000000000..7d508b972 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1704186 @@ -0,0 +1,10 @@ + +no option for handling ^C in stdio + +There is no way to tell qemu to handle (or not) ^C on standard input. + +This makes using serial console on stdio needlessly annoying and difficult. + +The code is there - depending on how you set up the console it may handle the signal or not. + +That's completely backwards. The behavior should be the same regardless of how you set up console *and* there should be a separate option for handling ^C. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1704658 b/results/classifier/accel-gemma3:12b/vmm/1704658 new file mode 100644 index 000000000..5f421560e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1704658 @@ -0,0 +1,21 @@ + +O_CLOEXEC not handled in dup3 system call in user mode + +In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag. + +When the attached program runs, the expected output is: +errno=9=EBADF + +How to reproduce on hppa: +- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa +- Set environment variables for running qemu-hppa. +- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed + +How to reproduce on sparc64: +- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64 +- Set environment variables for running qemu-sparc64. +- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64 +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1707587 b/results/classifier/accel-gemma3:12b/vmm/1707587 new file mode 100644 index 000000000..62a9e7d06 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1707587 @@ -0,0 +1,9 @@ + +Read certificate from USB key failed + +QEMU release version: qemu-2.9.0 +VM operation system: win7 32bit + +I have an usb key which can be redirected and recognized in VM. However, it is failed to get the certificate when using the official application for this usb key. What's more, the whole app is stalled untill this usb key detached from VM. + +As I researched, this usb key uses interrupt transfers when application trying to read certificate from it. Problem is that some certificate data abandoned by "usbredir_stop_interrupt_receiving" and "usbredir_stop_ep". The two functions use "usbredir_free_bufpq" to clear the buffered usb packets, even the certificate remain in the bufpq. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1708 b/results/classifier/accel-gemma3:12b/vmm/1708 new file mode 100644 index 000000000..24c7c7120 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1708 @@ -0,0 +1,68 @@ + +RISCV: Illegal instruction delegated to VS mode sets the wrong vscause value +Description of problem: +When delegating an illegal instruction exception caused in VS-mode to VS-mode, the vscause value for an illegal instruction is set incorrectly. + +Steps to reproduce: +1. Delegate 2(,6,10) in medeleg and hedeleg. +2. Enter VS-mode +3. Cause an illegal instruction fault, cause 6 can't happen in QEMU since there is misaligned support and 10 can't be delegated to VS mode. +4. The (v)scause CSR is then set to 1, i.e. instruction access fault which isn't correct. + +I have located the issue in the code @ cpu_helper.c:1703 +``` +if ((cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` + +The if statement should include a check for the async otherwise the cause shouldn't be altered. The patch I propose is simply to **and** the current statement with async. +``` +if (async & (cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` +Additional information: +Log where the incorrect cause is set. Note this line: `DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0` +``` +TRACE: [src/hart_ctrl.c:35] STARTING CPU 0 +TRACE: [src/page_tables.c:343] Setting up page tables between 0x80000000 -> 0x81c00000 +TRACE: [src/page_tables.c:359] Setting up page tables between 0x81c01000 -> 0x81c02000 +TRACE: [src/page_tables.c:374] Setting up page tables for UART 0x10000000 +TRACE: [src/page_tables.c:386] Setting up page tables for CLINT 0x2000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x24000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28001000 +TRACE: [src/main.c:32] STARTING HYPERVISOR TESTS +DEBUG: [src/util_fn.c:1175] pmpcfg0 = 0x00000000000f000f +DEBUG: [src/util_fn.c:1176] pmpcfg2 = 0x0000000000000000 +PMP Entry : 0 +Low Address : 0x0 +High Address : 0x81c00000 +Address Range : 0x0 - 0x81c00000 +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +PMP Entry : 2 +Low Address : 0x82000000 +High Address : 0xfffffffffffffffc +Address Range : 0x82000000 - 0xfffffffffffffffc +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +DEBUG: [src/trap_trigger.c: 85] Switching mode to VS +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x00000000800062a4, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 102] Illegal instruction exception: MEPC = 0x800062a4, MTVAL = 0x0 +TRACE: [src/util_fn.c:374] Done switching mode +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x0000000080008850, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0 +ERROR: [src/trap_handling.c:158] The following assert failed: mask_cause == cause2check +mask_cause = 0x1 diff --git a/results/classifier/accel-gemma3:12b/vmm/1708215 b/results/classifier/accel-gemma3:12b/vmm/1708215 new file mode 100644 index 000000000..3e0d04604 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1708215 @@ -0,0 +1,26 @@ + +Windows 10 clipboard bug + +Hello, + +I am using qemu on arch: + pacman -Q libvirt qemu linux virt-manager +libvirt 3.5.0-1 +qemu 2.9.0-2 +linux 4.12.3-1 +virt-manager 1.4.1-2 + +I have a windows 10 Guest, with all updates and the following packages installed in the guest: +- QEMU guest agent 7.3.2 +- SPICE Guest Tools 0.132 + +When I start the VM, I can copy/paste from the host to the guest. However, after I use COPY inside the VM, copy/paste is not working any more from host to guest. However, I can still copy/paste from guest to host. + +To summarize: +- copy/paste from guest to host works always +- copy/paste from host to guest works only if copy was not previously used in guest. + +If this bug needs to be reported using another portal or if I can provide any further information, please contact me. + +Best Regards, +gxgung \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1708462 b/results/classifier/accel-gemma3:12b/vmm/1708462 new file mode 100644 index 000000000..35f693f94 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1708462 @@ -0,0 +1,4 @@ + +Support Python 3 to build + +Currently qemu's configure requires Python 2 to build. As Python 2 is rapidly approaching its EOL, it should be possible to build qemu with Python 3. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1708551 b/results/classifier/accel-gemma3:12b/vmm/1708551 new file mode 100644 index 000000000..acf6b9421 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1708551 @@ -0,0 +1,18 @@ + +macOS Guest Reading USB 3.0 Bus as USB 2.0 + +Description: +I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes. + +Parameters: +QEMU release version: 2.10.0-rc0 +Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)] +Command Line: https://pastebin.com/pBSYbrW1 +Host: Arch Linux +Guest: macOS v10.12.6 +Guest System Info: https://pastebin.com/U1Tihxei + +Notes: +1. Observed sometime after late-May-early-June of this year. + +2. Due to [a defect in qemu v2.8 which affected GTK users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent change to macOS' booting process conflicting with qemu v2.9](https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as -rc1 fails to load OVMF right now). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1709025 b/results/classifier/accel-gemma3:12b/vmm/1709025 new file mode 100644 index 000000000..e08489b5a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1709025 @@ -0,0 +1,40 @@ + +Disk corrupted after snapshot deletion + + I found the vm disk corruption after snapshot deletion sometimes(the probability is very low, I'm afraid i can't reproduce it). And I found there is a patch for it as follow, but I'm not sure whether the patch repaired the bug. + Drain disk before snapshot deletion can't guarantee anything, there is still pending IO in snapshot-deletion process. Anyone can help? + +author Zhang Haoyu <email address hidden> 2014-10-21 16:38:01 +0800 +committer Stefan Hajnoczi <email address hidden> 2014-11-03 09:48:42 +0000 +commit 3432a1929ee18e08787ce35476abd74f2c93a17c (patch) +tree 13a81c0a46707d91622f1593ccf7b926935371fd /block/snapshot.c +parent 573742a5431a99ceaba6968ae269cee247727cce (diff) +snapshot: add bdrv_drain_all() to bdrv_snapshot_delete() to avoid concurrency problem +If there are still pending i/o while deleting snapshot, +because deleting snapshot is done in non-coroutine context, and +the pending i/o read/write (bdrv_co_do_rw) is done in coroutine context, +so it's possible to cause concurrency problem between above two operations. +Add bdrv_drain_all() to bdrv_snapshot_delete() to avoid this problem. + +Signed-off-by: Zhang Haoyu <email address hidden> +Reviewed-by: Paolo Bonzini <email address hidden> +Message-id: <email address hidden> +Signed-off-by: Stefan Hajnoczi <email address hidden> +Diffstat (limited to 'block/snapshot.c') +-rw-r--r-- block/snapshot.c 4 +1 files changed, 4 insertions, 0 deletions +diff --git a/block/snapshot.c b/block/snapshot.c +index 85c52ff..698e1a1 100644 +--- a/block/snapshot.c ++++ b/block/snapshot.c +@@ -236,6 +236,10 @@ int bdrv_snapshot_delete(BlockDriverState *bs, + error_setg(errp, "snapshot_id and name are both NULL"); + return -EINVAL; + } ++ ++ /* drain all pending i/o before deleting snapshot */ ++ bdrv_drain_all(); ++ + if (drv->bdrv_snapshot_delete) { + return drv->bdrv_snapshot_delete(bs, snapshot_id, name, errp); + } \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1712 b/results/classifier/accel-gemma3:12b/vmm/1712 new file mode 100644 index 000000000..905cf09d8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1712 @@ -0,0 +1,10 @@ + +Arabic keyboard layout wrong. +Description of problem: +After a while the compilation process starts, xkb gives an error about symbols/ar not found. According to my research, linux distros using "ara" for arabic layout. But qemu pc-bios/keymaps/ folder contains "ar" for arabic layout. +Steps to reproduce: +1.Configure +2.Build +3.Wait until error appears. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1712027 b/results/classifier/accel-gemma3:12b/vmm/1712027 new file mode 100644 index 000000000..8e79c35fe --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1712027 @@ -0,0 +1,46 @@ + +qemu: Cryptography adding encrypted disk with luks format failed + +I'm using libvirt to attach luks encrypted disk to a running VM. The qemu-monitor-command like the + +following: + +{"execute":"object-add","arguments":{"qom-type":"secret","id":"virtio-disk11-luks-secret0","props":{"data":"El7jOYLCZwrij2Mue0q2tA==","keyid":"masterKey0","iv":"J2je0WJjCa89L3iKc1lceg==","format":"base64"}} + +the masterKey0 specify the secret which has been created before. + +command above return with error message "Incorrect number of padding bytes XXX found on decrypted + +data". This is triggered by the following code snippets in qemu/crypto/secret.c: + +if (plaintext[ciphertextlen - 1] > 16 || + plaintext[ciphertextlen - 1] > ciphertextlen) { + error_setg(errp, "Incorrect number of padding bytes (%d) " + "found on decrypted data", + (int)plaintext[ciphertextlen - 1]); + … + } + +The bug is: There is on padding in plaintext if the actual length of the plaintext decrypted is + +equal to ciphertext. + +In this case, the last element in plaintext array may be one of the character in base64 code table + +or other. + +I would like to know why length of padding bytes cannot exceed 16 and whether i can remove + +judement: “plaintext[ciphertextlen - 1] > 16” so that I can eliminate the error above. + +Much appreciate it if doubts above is cleared up. + +libvirt/qemu version: + +# virsh version +Compiled against library: libvirt 3.0.0 +Using library: libvirt 3.0.0 +Using API: QEMU 3.0.0 +Running hypervisor: QEMU 2.7.1 + +OS: Ubuntu 12.04 LTS \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1712564 b/results/classifier/accel-gemma3:12b/vmm/1712564 new file mode 100644 index 000000000..aa86d8ffb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1712564 @@ -0,0 +1,26 @@ + +loadvm fails twice in sequence + +13:38:23) shorne_: Hello, I was doing some testing with migrations for my OpenRISC SMP patch set, I noticed something that looks like a bug, wondering if someone else wants to confirm +(13:38:47) shorne_: Basically, calling loadvm 2 times causes crash +(13:38:54) shorne_: migration/savevm.c: qemu_event_set(&mis->main_thread_load_event) +(13:38:54) stefanha: fam: Here is my take at this change: https://paste.debian.net/982690/ +(13:38:56) shorne_: assert(ev->initialized) - fails inside +(13:39:32) stefanha: quintela davidgiluk: ^ +(13:41:23) ***davidgiluk looks +(13:41:40) shorne_: c096358e747 util/qemu-thread-posix.c (Fam Zheng 2017-07-04 20:23:25 +0800 397) assert(ev->initialized); +(13:41:51) davidgiluk: shorne_: So you're doing a loadvm to load a snapshot and then again? +(13:42:02) shorne_: Looks like adding that assert() was done really recently +(13:42:41) shorne_: yes, just loadvm 'a' ... then wait a bit longer, loadvm 'a' again (confirm clocks go back etc) +(13:42:50) stefanha: fam: While you're having dinner I'll work on turning my script into a qemu-iotests test case that we can merge. +(13:44:03) gpiccoli [~gpiccoli@0002093a.user.oftc.net] entered the room. +(13:44:21) davidgiluk: shorne_: Well, it looks like the c09635 assert is a sanity check to make sure we didn't do anything stupid, and well..... +(13:44:57) pm215: migration_incoming_get_current() and migration_incoming_state_destroy() seem a bit mismatched +(13:45:13) davidgiluk: pm215: Yep +(13:45:46) davidgiluk: pm215: Generally we've thought that an incoming migration normally only happens once - shorne_'s case is the exception +(13:46:03) shorne_: pm215: yeah, it looked something like that I just had a few seconds to look at today +(13:46:03) HariharanTS left the room (quit: Ping timeout: 480 seconds). +(13:46:03) shorne_ is now known as shorne +(13:48:05) shorne: davidgiluk: pm215: thanks for having a look. Unfortunately I need to head off to bed and put kids to sleep +(13:49:11) davidgiluk: shorne: Sleep well, no nightmares about event destroyers.... +(13:49:30) davidgiluk: pm215: Yeh this is fall out from b4b076daf32 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1713328 b/results/classifier/accel-gemma3:12b/vmm/1713328 new file mode 100644 index 000000000..47407fc65 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1713328 @@ -0,0 +1,10 @@ + +Unable to C-a in -nographic if -serial telnet + +qemu-system-i386 (version 2.6.1, running on Linux/x86_64) started with: + +qemu-system-i386 -m 64M -machine type=pc -rtc base=localtime,clock=host -nographic -serial telnet:127.0.0.1:1234,server,nowait -net nic,model=ne2k_pci -net user,hostfwd=tcp:127.0.0.1:2200-:22,tftp=/ + +does not accept the escape key (C-a) to perform functions such as switching from monitor to console. Verified both in GNU screen and in the Linux console. + +If '-serial telnet:127.0.0.1:1234,server,nowait' is removed from the command line, the escape key is accepted (and Qemu doesn't enter the monitor immediately). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1715186 b/results/classifier/accel-gemma3:12b/vmm/1715186 new file mode 100644 index 000000000..dc62c31bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1715186 @@ -0,0 +1,13 @@ + +websockets: Improve error messages + +Since 2.9 / 07e95cd529af345fdeea230913f68eff5b925bb6 , whenever the VNC websocket server finds an error with the incoming connection request, it just closes the socket with no further information. + +This makes figuring out what's wrong with the request nearly impossible. + +I would be nice if: + +* HTTP 400 were returned to the client, with an appropriate error message +* Maybe something written to the log as well? + +Currently, I'm resorting to looking at my request and the websocket source and hoping I can figure out what's wrong. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1715203 b/results/classifier/accel-gemma3:12b/vmm/1715203 new file mode 100644 index 000000000..afc0a971c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1715203 @@ -0,0 +1,8 @@ + +Maintain Haiku support + +It was pointed out that the 2.10 release notes are pushing to drop Haiku support. The qemu port is currently working as-is under Haiku. + +Was there a reason this was recommended? Is there anything Haiku can do to keep it from being dropped? + +We're working on a docker container to cross-compile rust-lang for Haiku, could this be of some use to qemu when complete? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1717414 b/results/classifier/accel-gemma3:12b/vmm/1717414 new file mode 100644 index 000000000..b86ecbd9d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1717414 @@ -0,0 +1,27 @@ + +Sending certain keysyms results in wrong symbol input + +I develop bVNC, an Android VNC client. I noticed that when I connect to qemu VMs that have a VNC console, Keysyms that are usually sent over with SHIFT modifier when connecting from a PC have wrong symbols typed within the VM. A very short list of examples: + +exclam 33 0x0021 + +results in "1" typed in the VM. + +at 64 0x0040 + +results in "2" + +plus 43 0x002b + +results in "=" + +asterisk 42 0x002a + +results in "8" + +On Android, KEYCODEs that correspond to the above keysyms do not come with SHIFT metastate. Therefore, the keysyms that they correspond to are not sent over with any modifiers and must just work. + +The issue was reproduced with bVNC and RealVNC viewers connecting to many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The qemu version that comes with oVirt 4.1 is 2.6.0, commit hash bfc766d38e1fae5767d43845c15c79ac8fa6d6af. + +Sincerely, +iordan \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1718719 b/results/classifier/accel-gemma3:12b/vmm/1718719 new file mode 100644 index 000000000..6bee704a9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1718719 @@ -0,0 +1,12 @@ + +qemu can't capture keys properly under wayland + +This appears to be different than the previous similar bugs; patches do look to be applied to use libinput in the wayland case. Still: + +unknown keycodes `(unnamed)', please report to <email address hidden> + +I am using qemu-system-x86 1:2.10+dfsg-0ubuntu1 + +Many key inputs work correctly, but at boot the system will not properly catch the arrow keys, the above error shows up immediately after hitting Esc (for instance) to get to the boot menu. Booting from CD onto a daily Ubuntu desktop image, I can't navigate the splash menu. + +The same works correctly through virt-manager (which uses spice AFAICT, but wayland tends to crash when running virt-manager), and things work if I switch my session to Xorg rather than wayland. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1718964 b/results/classifier/accel-gemma3:12b/vmm/1718964 new file mode 100644 index 000000000..4d6308ae9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1718964 @@ -0,0 +1,73 @@ + +Memory leak when using websocket over a low speed network + +Description of problem +------------------------- + +When VNC is connected to QEMU via websocket over a low speed network (e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer update, the VNC Client will get stuck, the cursor is almost impossible to move, which may result in accumulation of a large number of data in the QEMU process (memory consumption will keep increasing). + + +Environment +------------------------- +All of the following versions have been tested: + +QEMU: 2.5.1 / 2.6.0 / 2.8.1.1 / 2.9.0 / 2.10.0 +Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 +Guest OS: Windows 7 64bit / Ubuntu 16.04 Desktop LTS +Client OS: Windows 7 64bit / Windows 10 64bit +Client Browser: IE 11.0.9600 / Chrome 60.0.3112 / Firefox 55.0.2 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 +VNC Web Client: noVNC 0.5.1 / noVNC 0.61 / noVNC 0.62 +VNC Server: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 + + +Steps to reproduce: +------------------------- +100% reproducible. + +1. Launch a QEMU instance with websocket option: +qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :1,websocket=5701 + +2. Open VNC Web Client (noVNC/vnc.html) in browser and connect to QEMU VM via websocket + +3. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) + +4. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) + +5. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move + +6. Observe QEMU process on the host, more and more data are accumulated in the process, the consumption of memory continues to keep increasing + + +Current result: +------------------------- +[Top - Initial status] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7229144 5.910g 23024 S 16.3 18.9 0:12.84 qemu-system-x86_64 + +[Top - After an hour's playing w/o limit (6-8MB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7370284 6.046g 23132 S 28.0 19.3 35:58.15 qemu-system-x86_64 + +[Top - Limit the bandwidth and continue to playing for another an hour (300KB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 11.029g 8.853g 23132 S 20.0 28.2 72:14.17 qemu-system-x86_64 + +Also test several other combinations in the same environment: + +1. Client(VNC Viewer) - Server(QEMU) +2. Client(VNC Viewer) - Server(tigervnc/x11vnc/tightvnc) +3. Client(noVNC) - Server(tigervnc/x11vnc/tightvnc) + +Likewise, the client's inbound bandwidth is limited to 300KB/S, +although a lot of frame are lost, all of they still works (at least the mouse is movable). + +It's found that when connect to QEMU via websocket, it never drop any frames. +QEMU still sends a lot of data to its websocket even when the network is congested, +the process is continually consuming more memory, then it gets stack. + + +Expected results: +------------------------- +When the network is poor (non-LAN), QEMU would reduce the VNC data send to its websocket correspondingly, and the memory usage remains stable. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1719196 b/results/classifier/accel-gemma3:12b/vmm/1719196 new file mode 100644 index 000000000..7b333b845 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1719196 @@ -0,0 +1,146 @@ + +[arm64 ocata] newly created instances are unable to raise network interfaces + +arm64 Ocata , + +I'm testing to see I can get Ocata running on arm64 and using the openstack-base bundle to deploy it. I have added the bundle to the log file attached to this bug. + +When I create a new instance via nova, the VM comes up and runs, however fails to raise its eth0 interface. This occurs on both internal and external networks. + +ubuntu@openstackaw:~$ nova list ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| ID | Name | Status | Task State | Power State | Networks | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| dcaf6d51-f81e-4cbd-ac77-0c5d21bde57c | sfeole1 | ACTIVE | - | Running | internal=10.5.5.3 | +| aa0b8aee-5650-41f4-8fa0-aeccdc763425 | sfeole2 | ACTIVE | - | Running | internal=10.5.5.13 | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +ubuntu@openstackaw:~$ nova show aa0b8aee-5650-41f4-8fa0-aeccdc763425 ++--------------------------------------+----------------------------------------------------------+ +| Property | Value | ++--------------------------------------+----------------------------------------------------------+ +| OS-DCF:diskConfig | MANUAL | +| OS-EXT-AZ:availability_zone | nova | +| OS-EXT-SRV-ATTR:host | awrep3 | +| OS-EXT-SRV-ATTR:hypervisor_hostname | awrep3.maas | +| OS-EXT-SRV-ATTR:instance_name | instance-00000003 | +| OS-EXT-STS:power_state | 1 | +| OS-EXT-STS:task_state | - | +| OS-EXT-STS:vm_state | active | +| OS-SRV-USG:launched_at | 2017-09-24T14:23:08.000000 | +| OS-SRV-USG:terminated_at | - | +| accessIPv4 | | +| accessIPv6 | | +| config_drive | | +| created | 2017-09-24T14:22:41Z | +| flavor | m1.small (717660ae-0440-4b19-a762-ffeb32a0575c) | +| hostId | 5612a00671c47255d2ebd6737a64ec9bd3a5866d1233ecf3e988b025 | +| id | aa0b8aee-5650-41f4-8fa0-aeccdc763425 | +| image | zestynosplash (e88fd1bd-f040-44d8-9e7c-c462ccf4b945) | +| internal network | 10.5.5.13 | +| key_name | mykey | +| metadata | {} | +| name | sfeole2 | +| os-extended-volumes:volumes_attached | [] | +| progress | 0 | +| security_groups | default | +| status | ACTIVE | +| tenant_id | 9f7a21c1ad264fec81abc09f3960ad1d | +| updated | 2017-09-24T14:23:09Z | +| user_id | e6bb6f5178a248c1b5ae66ed388f9040 | ++--------------------------------------+----------------------------------------------------------+ + + + +As seen above the instances boot an run. Full Console output is attached to this bug. + + +[ OK ] Started Initial cloud-init job (pre-networking). +[ OK ] Reached target Network (Pre). +[ OK ] Started AppArmor initialization. + Starting Raise network interfaces... +[FAILED] Failed to start Raise network interfaces. +See 'systemctl status networking.service' for details. + Starting Initial cloud-init job (metadata service crawler)... +[ OK ] Reached target Network. +[ 315.051902] cloud-init[881]: Cloud-init v. 0.7.9 running 'init' at Fri, 22 Sep 2017 18:29:15 +0000. Up 314.70 seconds. +[ 315.057291] cloud-init[881]: ci-info: +++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++ +[ 315.060338] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.063308] cloud-init[881]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | +[ 315.066304] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.069303] cloud-init[881]: ci-info: | eth0: | True | . | . | . | fa:16:3e:39:4c:48 | +[ 315.072308] cloud-init[881]: ci-info: | eth0: | True | . | . | d | fa:16:3e:39:4c:48 | +[ 315.075260] cloud-init[881]: ci-info: | lo: | True | 127.0.0.1 | 255.0.0.0 | . | . | +[ 315.078258] cloud-init[881]: ci-info: | lo: | True | . | . | d | . | +[ 315.081249] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.084240] cloud-init[881]: 2017-09-22 18:29:15,393 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0xffffb10794e0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))] + + + + +---------------- + + + +I have checked all services in neutron and made sure that they are running and restarted in neutron-gateway + + + [ + ] neutron-dhcp-agent + [ + ] neutron-l3-agent + [ + ] neutron-lbaasv2-agent + [ + ] neutron-metadata-agent + [ + ] neutron-metering-agent + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + +and have also restarted and checked the nova-compute logs for their neutron counterparts. + + + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + + + + There are some warnings/errors in the neutron-gateway logs which I have attached the full tarball in a separate attachment to this bug: + +2017-09-24 14:39:33.152 10322 INFO ryu.base.app_manager [-] instantiating app ryu.controller.ofp_handler of OFPHandler +2017-09-24 14:39:33.153 10322 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-24 14:39:39.577 10322 ERROR neutron.agent.ovsdb.impl_vsctl [req-2f084ae8-13dc-47dc-b351-24c8f3c57067 - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID e02a5f7f-bfd2-4a1d-ae3c-0321db4bd3fb, existed in the database before this transaction and was not modified by the transaction. Second row, with UUID 6e9aba3a-471a-4976-bffd-b7131bbe5377, was inserted by this transaction.","error":"constraint violation"} + + + +These warnings/errors also occur on the nova-compute hosts in /var/log/neutron/ + + + + +2017-09-22 18:54:52.130 387556 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-22 18:54:56.124 387556 ERROR neutron.agent.ovsdb.impl_vsctl [req-e291c2f9-a123-422c-be7c-fadaeb5decfa - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID 9f27ddee-9881-4cbc-9777-2f42fee735e9, was inserted by this transaction. Second row, with UUID ccf0e097-09d5-449c-b353-6b69781dc3f7, existed in the database before this transaction and was not modified by the transaction.","error":"constraint violation"} + + + +I'm not sure if the above error could be pertaining to the failure, I have also attached those logs to this bug as well... + + +. +(neutron) agent-list ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| id | agent_type | host | availability_zone | alive | admin_state_up | binary | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| 0cca03fb-abb2-4704-8b0b-e7d3e117d882 | DHCP agent | awrep1 | nova | :-) | True | neutron-dhcp-agent | +| 14a5fd52-fbc3-450c-96d5-4e9a65776dad | L3 agent | awrep1 | nova | :-) | True | neutron-l3-agent | +| 2ebc7238-5e61-41f8-bc60-df14ec6b226b | Loadbalancerv2 agent | awrep1 | | :-) | True | neutron-lbaasv2-agent | +| 4f6275be-fc8b-4994-bdac-13a4b76f6a83 | Metering agent | awrep1 | | :-) | True | neutron-metering-agent | +| 86ecc6b0-c100-4298-b861-40c17516cc08 | Open vSwitch agent | awrep1 | | :-) | True | neutron-openvswitch-agent | +| 947ad3ab-650b-4b96-a520-00441ecb33e7 | Open vSwitch agent | awrep4 | | :-) | True | neutron-openvswitch-agent | +| 996b0692-7d19-4641-bec3-e057f4a856f6 | Open vSwitch agent | awrep3 | | :-) | True | neutron-openvswitch-agent | +| ab6b1065-0b98-4cf3-9f46-6bddba0c5e75 | Metadata agent | awrep1 | | :-) | True | neutron-metadata-agent | +| fe24f622-b77c-4eed-ae22-18e4195cf763 | Open vSwitch agent | awrep2 | | :-) | True | neutron-openvswitch-agent | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ + + +Should neutron-openvswitch be assigned to the 'nova' availability zone? + +I have also attached the ovs-vsctl show from a nova-compute host and the neutron-gateway host to ensure that the open v switch routes are correct. + + +I can supply more logs if required. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1721744 b/results/classifier/accel-gemma3:12b/vmm/1721744 new file mode 100644 index 000000000..129c22657 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1721744 @@ -0,0 +1,53 @@ + +Help content missing for newly added machine properties + + +Help content missing for newly added machine properties, it would be needed by libvirt and other management layers to query to add support, Thanks. + +max-cpu-compat,vsmt,modern-hotplug-events,resize-hpt + +Steps: +1. Compile qemu @below commit +2. ./ppc64-softmmu/qemu-system-ppc64 -h +.... +-machine [type=]name[,prop[=value][,...]] + selects emulated machine ('-machine help' for list) + property accel=accel1[:accel2[:...]] selects accelerator + supported accelerators are kvm, xen, hax or tcg (default: tcg) + kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + vmport=on|off|auto controls emulation of vmport (default: auto) + kvm_shadow_mem=size of KVM shadow MMU in bytes + dump-guest-core=on|off include guest memory in a core dump (default=on) + mem-merge=on|off controls memory merge support (default: on) + igd-passthru=on|off controls IGD GFX passthrough support (default=off) + aes-key-wrap=on|off controls support for AES key wrapping (default=on) + dea-key-wrap=on|off controls support for DEA key wrapping (default=on) + suppress-vmdesc=on|off disables self-describing migration (default=off) + nvdimm=on|off controls NVDIMM support (default=off) + enforce-config-section=on|off enforce configuration section migration (default=off) + s390-squash-mcss=on|off controls support for squashing into default css (default=off) +.... + +===> Not showing help of mentioned properties. + + + +Verified at todays below commit +#git show +commit d8f932cc696250cb740240d668b39df5fbb2d5a0 +Merge: 67caeea 4504273 +Author: Peter Maydell <email address hidden> +Date: Thu Oct 5 16:54:29 2017 +0100 + + Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging + + # gpg: Signature made Thu 05 Oct 2017 15:25:21 BST + # gpg: using RSA key 0x9CA4ABB381AB73C8 + # gpg: Good signature from "Stefan Hajnoczi <email address hidden>" + # gpg: aka "Stefan Hajnoczi <email address hidden>" + # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 + + * remotes/stefanha/tags/tracing-pull-request: + checkpatch: fix incompatibility with old perl + + Signed-off-by: Peter Maydell <email address hidden> \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1723488 b/results/classifier/accel-gemma3:12b/vmm/1723488 new file mode 100644 index 000000000..f72ef01fb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1723488 @@ -0,0 +1,38 @@ + +HAX on Windows, memory lease error + +Today I tried to use QEMU on Windows 8.1 x64 with Intel HAX. + +Command line: qemu-system-x86_64.exe -accel hax -m 8000 -hda /opt/disk/ubuntu.img -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso + +Host machine has 32Gb physical memory, I got error: + +HAX is working and emulator runs in fast virt mode. +** +ERROR:A:/msys64/home/admin/git/qemu/target/i386/hax-mem.c:210:hax_process_section: assertion failed: (size <= UINT32_MAX) + +When using -m 4000 (and below) everything is fine. But if I try use >4000 and <8000 I get crash with errors: + +HAX is working and emulator runs in fast virt mode. +hax_transaction_commit: Failed mapping @0x0000000100000000+0x78800000 flags 00 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1723927 b/results/classifier/accel-gemma3:12b/vmm/1723927 new file mode 100644 index 000000000..0e4d7debf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1723927 @@ -0,0 +1,18 @@ + +Linux or windows guest boot failed by uefi on CPU of Intel Xeon X5675 + +Hi, + +I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and start process stop on +"TianoCore" image by looking at VNCviewer. + +VM using the command:(redhat7.0) +/usr/bin/kvm -name guest=ytest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/run/lib/libvirt/qemu/domain-40-ytest/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,system=windows,dump-guest-core=off -bios /usr/share/qemu-kvm/OVMF_CODE.fd -m size=8388608k,slots=10,maxmem=34359738368k -realtime mlock=off -smp 1,maxcpus=24,sockets=24,cores=1,threads=1 -numa node,nodeid=0,cpus=0-23,mem=8192 -uuid 8cf40bd6-258a-4550-ba4e-b38230547a11 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -chardev socket,id=charmonitor_cas,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock.cas,server,nowait -mon chardev=charmonitor_cas,id=monitor_cas,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x3 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x4 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device usb-hub,id=hub0,bus=usb.0,port=1 -drive file=/vms/hw235/ytest,format=qcow2,if=none,id=drive-virtio-disk0,cache=directsync,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,pci_hotpluggable=on,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-fdc0-0-0,readonly=on -global isa-fdc.driveA=drive-fdc0-0-0 -global isa-fdc.bootindexA=2 -netdev tap,fd=48,id=hostnet0,vhost=on,vhostfd=50 -device virtio-net-pci,pci_hotpluggable=on,netdev=hostnet0,id=net0,mac=0c:da:41:1d:67:6f,bus=pci.0,addr=0x5,bootindex=4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/ytest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 0.0.0.0:9 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on + +qemu version: 2.7.1 +edk2 version: git://git.code.sf.net/p/tianocore/edk2.git, commit: cc0b456a05f8dd1ebfb9be485465be37e96999e7 +server: ProLiant BL460c G7, CPU: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz + +Another, last version of edk2(compiled by myself) start guest is failed, too. But r15214 of edk2 start guest is ok(Download from http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip) + +Thanks in Advance \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1724570 b/results/classifier/accel-gemma3:12b/vmm/1724570 new file mode 100644 index 000000000..a2da06f45 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1724570 @@ -0,0 +1,40 @@ + +qemu-system-x86_64 generates ACPI tables with broken endianess when run on big-endian hosts + +The bios-tables-test always fails when run on a big-endian host, which has iasl installed. When it calls iasl to dumps the AML files into ASL files, iasl complains + +Intel ACPI Component Architecture +ASL+ Optimizing Compiler/Disassembler version 20170831 +Copyright (c) 2000 - 2017 Intel Corporation + +Input file aml-4L677Y, Length 0x38 (56) bytes +Table [TEPH] is too long for file - needs: 0x38000000, remaining in file: 0x38 +Could not get ACPI tables from aml-4L677Y, AE_BAD_HEADER + + +At first I thought this was an iasl bug, but the latest version of iasl in rawhide is ported to big endian. + +So I looked at the actual AML files that bios-tables-test extracts from the qemu-system-x86_64 memory space, when running on ppc64 host. These do indeed have different content from the AML files generated by qemu-system-x86_64 when running on an x86_64 host. + + +eg the AML file for the HPET shows + +< 0000000 T E P H nul nul nul 8 soh etx B O C H S sp +< 4554 4850 0000 3800 0301 4f42 4843 2053 +< 0000020 B X P C H P E T nul nul nul soh B X P C +< 5842 4350 5048 5445 0000 0100 5842 4350 +< 0000040 nul nul nul soh soh " ack nul nul nul nul nul nul nul P ~ +< 0000 0100 a201 8086 0000 0000 0000 fed0 +--- +> 0000000 H P E T 8 nul nul nul soh etx B O C H S sp +> 5048 5445 0038 0000 0301 4f42 4843 2053 +> 0000020 B X P C H P E T soh nul nul nul B X P C +> 5842 4350 5048 5445 0001 0000 5842 4350 +> 0000040 soh nul nul nul soh " ack nul nul nul nul nul nul nul P ~ +> 0001 0000 a201 8086 0000 0000 0000 fed0 + +so not only is the table name inverted, but the lenght is inverted, and several fields later on are inverted too. + +Other AML files for APIC and DSDT show similar brokenness + +This is seen with QEMU 2.10.0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1724590 b/results/classifier/accel-gemma3:12b/vmm/1724590 new file mode 100644 index 000000000..aa893c351 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1724590 @@ -0,0 +1,6 @@ + +Usermode networking hostfwd only listens on IPv4 + +When forwarding ports in usermode networking (-net user,hostfwd=), QEMU binds to IPv4 only. Therefore, connecting to the port over IPv6 results in 'connection refused'. + +I experienced this in QEMU 2.10.1, but it looks to still be present in the current master (861cd431c99e56ddb5953ca1da164a9c32b477ca), since slirp_hostfwd in net/slirp.c uses in_addr instead of in6_addr. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1725707 b/results/classifier/accel-gemma3:12b/vmm/1725707 new file mode 100644 index 000000000..07a22f4ee --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1725707 @@ -0,0 +1,62 @@ + +QEMU sends excess VNC data to websockify even when network is poor + +Description of problem +------------------------- +In my latest topic, I reported a bug relate to QEMU's websocket: +https://bugs.launchpad.net/qemu/+bug/1718964 + +It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. +That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. +So I did a test and found that there indeed existed some problems. The problem is: + +When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. + +Environment +------------------------- +All of the following versions have been tested: + +QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) +Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 +Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master +VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master +Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 + +Steps to reproduce: +------------------------- +100% reproducible. + +1. Launch a QEMU instance (No need websocket option): +qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 + +2. Launch websockify on a separate host and connect to QEMU's VNC port + +3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify + +4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) + +5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) + +6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move + +7. Monitor network traffic on the proxy server + +Current result: +------------------------- +Monitor Downlink/Uplink network traffic on the proxy server +(Refer to the attachments for more details). + +1. Used with QEMU +- D: 5.9 MB/s U: 5.7 MB/s (Client on LAN) +- D: 4.3 MB/s U: 334 KB/s (Client on WAN) + +2. Used with other VNC servers +- D: 5.9 MB/s U: 5.6 MB/s (Client on LAN) +- D: 369 KB/s U: 328 KB/s (Client on WAN) + +It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) +will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes. + +Expected results: +------------------------- +When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1728 b/results/classifier/accel-gemma3:12b/vmm/1728 new file mode 100644 index 000000000..1f6c50a2c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1728 @@ -0,0 +1,19 @@ + +blockdev parameter does not accept dots in pool name in json config +Description of problem: +I'm trying to provision a VM using qemu 6.2.0 and pass the remote disk parameters like libvirt. When I start the VM, I get an error saying + + +``` +qemu-system-x86_64: -blockdev {driver:rbd,pool:cloud.disk.hiops,image:csi-vol-8577fffd-0f48-3344-b333-02000038163a,server:[{host:1.2.3.4,port:6789},{host:1.2.3.5,port:6789},{host:1.2.3.6,port:6789}],user:compute-staging,auth-client-required:[cephx,none],key-secret:ceph-secret,node-name:pv-MD7PBV3SRD21L08115JUJ94HMG,cache:{direct:false,no-flush:false},auto-read-only:true,discard:unmap}: JSON parse error, stray '.' +``` + + +I changed the ip address and some fields. + + +My question is should we avoid dots in pool name? I tried to look at the source code of json parser but in its doc, it did not mention a sequence of characters for escaping dots. +Steps to reproduce: +1. Provision a VM with the provided config +Additional information: +bl diff --git a/results/classifier/accel-gemma3:12b/vmm/1728256 b/results/classifier/accel-gemma3:12b/vmm/1728256 new file mode 100644 index 000000000..16b7d89e6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1728256 @@ -0,0 +1,11 @@ + +Memory corruption in Windows 10 guest / amd64 + +I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 host. The VM has a physical GPU passed through, as well as the physical USB controllers, as well as a dedicated SSD attached via SATA; you can find the complete libvirt xml here: https://pastebin.com/U1ZAXBNg +I built qemu from source using the qemu-minimal-git AUR package; you can find the build script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you aren't familiar with Arch, this is essentially a bash script where build() and package() are run to build the files, and then install them into the $pkgdir to later tar them up.) + +Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0, which is running stable for over 50 hours right now. + +During my tests I found that locking the memory pages alleviates the problem somewhat, but never completely avoids it. However, with the crashes occuring randomly, that could as well be false conclusions; I had crashes within minutes after boot with that too. + +I will now start `git bisect`ing; if you have any other suggestions on what I could try or possible patches feel free to leave them with me. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1730 b/results/classifier/accel-gemma3:12b/vmm/1730 new file mode 100644 index 000000000..4258381f4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1730 @@ -0,0 +1,17 @@ + +Virtual console in GTK input uses wrong color for dark gray +Description of problem: +The virtual console in the GTK window uses black to draw dark gray text. This becomes unintelligible if drawing on black background. +Steps to reproduce: +1. Boot any distro to shell prompt with `-serial vc`. +2. Switch to serial console in QEMU GTK window (Ctrl+Alt+3). +4. Run `echo -e "\e[1;30mDark Greay\e[m"`. +5. Output is black on black. + +or + +1. `qemu-system-x86_64 -bios /usr/share/edk2/x64/OVMF.fd` +2. Enter EFI internal shell +3. `cls 0 8` +4. Run `help cls` and observe correct colors in VGA window. +5. Switch to serial console and observe black on black colors. diff --git a/results/classifier/accel-gemma3:12b/vmm/1731 b/results/classifier/accel-gemma3:12b/vmm/1731 new file mode 100644 index 000000000..c0453f3d1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1731 @@ -0,0 +1,13 @@ + +i440fx ide cdrom pathological slow on early win10 install screen +Description of problem: +if you choose i440fx virtual hardware (default in proxmox) for windows 10 instead of q35 , from power on to the windows boot logo is 10 times slower. you need to wait more then 1m45s on my hardware until the blinking cursor in the upper left goes away and the blue windows bootlogo appears. that leads to false assumption, that your setup hangs. + +what's causing this slownewss? + +is implementation really that bad? + +i did compare read performance of ide, sata and scsi cdrom in linux vm and cannot observe such a big difference. + +see +https://forum.proxmox.com/threads/win10-installation-pathological-slowness-with-i440fx-ide-cdrom.129351/ diff --git a/results/classifier/accel-gemma3:12b/vmm/1732679 b/results/classifier/accel-gemma3:12b/vmm/1732679 new file mode 100644 index 000000000..9db8dcf17 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1732679 @@ -0,0 +1,89 @@ + +Cisco NX-OSv 9k crashes during boot with qemu 2.10.1(Debian 1:2.10.0+dfsg-2) and ovmf 0~20161202.7bbe0b3e-1 + +Ubuntu 17.04 +qemu 2.10.1(Debian 1:2.10.0+dfsg-2) +gns3 2.0.3 +NX-OSv 9k 7.0.3.I6.1 + +- No such issue with previous qemu 2.8.x +- the issue does not seem to come from the debian packaging +- the issue does not seem to come from GNS3 either, as confirmed by Jeremy Grossmann at https://github.com/GNS3/gns3-server/issues/1193#issuecomment-344240460 + +Either some parameters usage have changed (for instance -bios) (which would make qemu not backwards compatible) or there is an issue with qemu itself. +The configuration parameters are: +``` + "compute_id": "local", + "console": 2010, + "console_type": "telnet", + "first_port_name": "mgmt0", + "height": 48, + "label": { + "rotation": 0, + "style": "font-family: TypeWriter;font-size: 10.0;font-weight: bold;fill: #000000;fill-opacity: 1.0;", + "text": "NX_OSv_9k_Spine_31", + "x": -54, + "y": -25 + }, + "name": "NX_OSv_9k_Spine_31", + "node_id": "8d01119a-0adc-41bc-950b-c5639db7708c", + "node_type": "qemu", + "port_name_format": "Ethernet1/{port1}", + "port_segment_size": 0, + "properties": { + "acpi_shutdown": false, + "adapter_type": "e1000", + "adapters": 10, + "bios_image": "", + "bios_image_md5sum": null, + "boot_priority": "c", + "cdrom_image": "", + "cdrom_image_md5sum": null, + "cpu_throttling": 0, + "cpus": 2, + "hda_disk_image": "NX-OSv-9k-7.0.3.I6.1.free.qcow2", + "hda_disk_image_md5sum": "18bb991b814a508d1190575f99deed99", + "hda_disk_interface": "ide", + "hdb_disk_image": "", + "hdb_disk_image_md5sum": null, + "hdb_disk_interface": "ide", + "hdc_disk_image": "", + "hdc_disk_image_md5sum": null, + "hdc_disk_interface": "ide", + "hdd_disk_image": "", + "hdd_disk_image_md5sum": null, + "hdd_disk_interface": "ide", + "initrd": "", + "initrd_md5sum": null, + "kernel_command_line": "", + "kernel_image": "", + "kernel_image_md5sum": null, + "legacy_networking": false, + "mac_address": "00:07:00:03:16:01", + "options": "-nographic -enable-kvm -cpu host -machine q35 -smp cpus=2 -bios /usr/share/ovmf/OVMF.fd", + "platform": "x86_64", + "process_priority": "normal", + "qemu_path": "/usr/bin/qemu-system-x86_64", + "ram": 6144, + "usage": "" +``` + +The logs are: +- [execution log](https://github.com/GNS3/gns3-server/files/1381651/qemu.log.txt) +- [terminal log](https://github.com/GNS3/gns3-server/files/1381660/terminal.log.txt) + +With the latest qemu, I can boot: +- Cisco IOSv 15.6(2)T +- Cisco IOSv-L2 15.2(20170321:233949) +- Cisco CSR 1000v 16.5.1b +- Cisco ASAv 9.6(2) + +The major difference with NX-OSv 9k is the bios parameter: ```-bios /usr/share/ovmf/OVMF.fd```: +``` +ll /usr/share/ovmf/OVMF.fd +-rw-r--r-- 1 root root 2097152 Dec 9 2016 /usr/share/ovmf/OVMF.fd +``` +A normal boot log with qemu 2.8.1 is available [here](https://github.com/GNS3/gns3-server/files/1381729/terminal.log.2.8.txt) + +Highlighting the differences: qemu 2.8.1 on the left, qemu 2.10.1 on the right hand side with the same boot parameters + \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1734810 b/results/classifier/accel-gemma3:12b/vmm/1734810 new file mode 100644 index 000000000..117e1778f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1735576 b/results/classifier/accel-gemma3:12b/vmm/1735576 new file mode 100644 index 000000000..d5d3e1e24 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1735576 @@ -0,0 +1,25 @@ + +Support more than 4G memory for guest with Intel HAXM acceleration + +setup: + +host: windows 7 professional 64bit +guest: centos 7 +qemu 2.10.92 +haxm 6.2.1 + +issue: when assign 4096M or more memory to the guest, I got following error message: +E:\qemuvm\vm-svr>qemu-system-x86_64 -accel hax -hda centos-1.vdi -m 4096 +HAX is working and emulator runs in fast virt mode. +Failed to allocate 0 memory +hax_transaction_commit: Failed mapping @0x0000000000000000+0xc0000000 flags 00 +hax_transaction_commit: Failed mapping @0x0000000100000000+0x40000000 flags 00 +VCPU shutdown request +VCPU shutdown request +if I change memory to 4095M, guest VM boot up without issue + +E:\qemuvm\vm-svr>qemu-system-x86_64 -accel hax -hda centos-1.vdi -m 4095 +HAX is working and emulator runs in fast virt mode. + + +This is known limitation, I already raised a request on HAXM github site for fix this: https://github.com/intel/haxm/issues/13, and it got accepted will be fixed in next haxm release; however it seems there is also qemu side work (according to haxm dev), so I raise this for qemu side fix; \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1738283 b/results/classifier/accel-gemma3:12b/vmm/1738283 new file mode 100644 index 000000000..885cb8544 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1738283 @@ -0,0 +1,12 @@ + +'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC + +If I start QEMU 2.11 (from https://build.opensuse.org/package/show/Virtualization/qemu) VM with VNC, I am unable to type following three characters: 'less than' (<), 'more than' (>), and 'pipe' (|) on en_US QWERTY keyboard. Other characters work fine. QEMu version 2.10.1 worked fine. + +/usr/bin/qemu-kvm -m 2048 -cpu kvm64 -drive media=cdrom,if=none,id=cd0,format=raw,file=OI-hipster-minimal-20171031.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -vnc :91,share=force-shared + +The ISO can be downloaded here: https://www.openindiana.org/download/ + +Also tried Fedora-Server-dvd-x86_64-25-1.3.iso and it's the same situation. + +If I run the same command without '-vnc :91,share=force-shared', everything works just fine. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1738507 b/results/classifier/accel-gemma3:12b/vmm/1738507 new file mode 100644 index 000000000..c68f9510d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1738507 @@ -0,0 +1,10 @@ + +qemu sometimes stuck when booting windows 10 + +I am using qemu-2.10.1, or actually libvirt, to create a virtual machine, running microsoft windows 10 pro operating system. +It installed fine and was actually working, however sometimes when trying to boot the vm, the whole boot process gets stuck. +For some reason, it seemed to happen only when enough physical memory is taken so that, when booting a windows vm that has 4gb of available ram, host starts swapping some other processes. It is not always happening there, but often it happens, and I do not remember seeing any case of this happening when not swapping, maybe a kind of a timing issue? +When this happens, I usually try to hard reset the machine by libvirt reset command or equivalent system_reset on qemu monitor, however the whole reset does not happen, and the command is a noop. That makes me think it is a qemu bug, not windows refusing operation. At the time of this event, qemu monitor and spice server are working correctly, are not stuck, and even doing things like system reset does not result in a monitor hang. It is also possible to quit qemu normally. +I tried to workaround the bug by guessing what may cause it. Switched from bios to uefi, changed virtio-scsi to ahci temporarily, and disabled virtio-balloon in case it would be buggy, with no visible change. +I will attach a libvirt log, because it contains qemu command line. I will also attach an example qemu backtrace. +From what i know, both vcpu threads are working normally, at least none of them is stuck in a vcpu, nor deadlocked, etc. So backtrace could be different each time I tried to get it. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1738771 b/results/classifier/accel-gemma3:12b/vmm/1738771 new file mode 100644 index 000000000..dcc02961b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1738771 @@ -0,0 +1,20 @@ + +qemu user does not provide AT_SECURE auxiliary vector entry + +When executing an android native binary using qemu in user mode, the program fail with the message + +FATAL: kernel did not supply AT_SECURE + +Android uses bionic libc.The linker requires that AT_SECURE is provided in the auxiliary vector, but qemu does not provide the entry. + +The issue can be reproduced using the commands: + +mkdir -p /tmp/android/system +cd /tmp/android +curl -O https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip +unzip sysimg_x86-21_r15.zip +mount -o loop x86/system.img system +qemu-i386 -L /tmp/android/ system/bin/ls + + +I've provided a patch (https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix the issue, but it was not reviewed yet. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1741718 b/results/classifier/accel-gemma3:12b/vmm/1741718 new file mode 100644 index 000000000..1ab491a81 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1741718 @@ -0,0 +1,87 @@ + +qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" with tribblix-sparc-0m16.iso + +qemu-system-sparc64 Niagara VM running Tribblix crashes with "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" on QEMU 2.11.0. Happens also with 1 GB, 4 GB, and 8 GB of RAM. + +$ qemu-system-sparc64 -nographic -M niagara -L /home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive if=pflash,readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 2048 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +hsfs-file-system +Loading: /platform/sun4v/boot_archive +ramdisk-root ufs-file-system +Loading: /platform/sun4v/kernel/sparcv9/unix +\ +panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found + +Warning - stack not written to the dumpbuf +000000000180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 81010100, ff00) + %l0-3: 0000000001876c00 ffffffffffffffff 00000000010d6c00 0000000000000000 + %l4-7: 800000008f000740 800000008fc54750 00000000f0254cc4 00000000010dedd0 +000000000180b800 unix:plat_lgrp_init+14 (4, 180e000, 4, 0, 180b950, 1) + %l0-3: 00000000fff32000 00000000fff340e0 00000000fff34590 00000000010d5f28 + %l4-7: 0000000000000016 0000000000000000 0000000000000016 0000000000000011 +000000000180b8b0 unix:lgrp_plat_init+74 (0, 0, 0, 180ba08, 180ba00, 91) + %l0-3: 0000000000002000 00000000fff34000 0000000001874c00 0000000001874c00 + %l4-7: 0000000000000000 0000000001874c00 000000000180b950 00000000010de048 +000000000180b960 unix:lgrp_init+4 (0, 2000, 70002000, 0, 180c0e8, 0) + %l0-3: 000000000180e380 000000000183c678 000000000180ba08 00000000010d4f90 + %l4-7: 00000000010d4fa0 00000000010d1c00 0000000000004000 0000000080001070 +000000000180ba10 unix:mlsetup+2f4 (180bb80, 180bec0, 0, 0, f025496c, 0) + %l0-3: 00000000018ee000 0000000070002000 0000000070002000 000000000180bad0 + %l4-7: 000000000190c4d8 00000001001f56e0 0000000000000000 0000000080001070 + + +ERROR: Last Trap: Level 14 Interrupt +[Exception handlers interrupted, please file a bug] +[type 'resume' to attempt a normal recovery] + + +Without "if=pflash" VM hangs: + +$ qemu-system-sparc64 -nographic -M niagara -L /home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 4096 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state +pc: 000000000040f01c npc: 000000000040f020 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000009700000280 +%g4-7: 0000000000001000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 000000008ffd6000 0000000000008000 0000000000000000 +%o4-7: 0000000000000000 00000000000000f0 00000000fff55701 00000000f020d78c +%l0-3: 000000000002fd10 7ffffffffffffffe 8000000000000000 0000000000000000 +%l4-7: 000000000000000b 800000008fffa750 00000000f026fbf0 00000000f022a0d8 +%i0-3: 0000000080000000 0000000010000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000014 ccr: 11 (icc: ---C xcc: ---C) asi: 20 tl: 6 pil: d gl: 6 +tbr: 00000000f0200000 hpstate: 0000000000000004 htba: 0000000000400000 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 0 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000004 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1743191 b/results/classifier/accel-gemma3:12b/vmm/1743191 new file mode 100644 index 000000000..a38739fbd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1743191 @@ -0,0 +1,42 @@ + +Interacting with NetBSD serial console boot blocks no longer works + +The NetBSD boot blocks display a menu allowing the user to make a +selection using the keyboard. For example, when booting a NetBSD +installation CD-ROM, the menu looks like this: + + 1. Install NetBSD + 2. Install NetBSD (no ACPI) + 3. Install NetBSD (no ACPI, no SMP) + 4. Drop to boot prompt + + Choose an option; RETURN for default; SPACE to stop countdown. + Option 1 will be chosen in 30 seconds. + +When booting NetBSD in a recent qemu using an emulated serial console, +making this menu selection no longer works: when you type the selected +number, the keyboard input is ignored, and the 30-second countdown +continues. In older versions of qemu, it works. + +To reproduce the problem, run: + + wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso + qemu-system-x86_64 -nographic -cdrom boot-com.iso + +During the 30-second countdown, press 4 + +Expected behavior: The countdown stops and you get a ">" prompt + +Incorrect behavior: The countdown continues + +There may also be some corruption of the terminal output; for example, +"Option 1 will be chosen in 30 seconds" may be displayed as "Option 1 +will be chosen in p0 seconds". + +Using bisection, I have determined that the problem appeared with qemu +commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was +updated to 1.11 prerelease, and the problem is still there as of +commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac. The host operating +system used for the tests was Debian 9 x86_64. + +Credit for discovering this bug goes to Paul Goyette. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1745312 b/results/classifier/accel-gemma3:12b/vmm/1745312 new file mode 100644 index 000000000..3e1dc3e03 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1745312 @@ -0,0 +1,590 @@ + +Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused] + +[Headsup: This report is long-ish due to the amount of detail I've stumbled on along the way that I think is relevant to include. I can't speak as to the complexity of the actual bugs, but the size of this report should not suggest that the reproduction process is particularly headache-inducing.] + +Hi! + +I recently needed to fire up some ancient software for research purposes and got very distracted discovering and playing with old versions of Windows :). In the process I've discovered some glitches with disk I/O. + +I believe I've stumbled on two completely separate issues that coincidentally surfaced at the same time. It's possible that components of this report will be re-filed as more specific new bugs, but I'm not an authority on QEMU internals or how to narrow down/categorize what I've found. + +- The first bug only surfaces when the "isapc" machine type is used. It intermittently produces "General failure {read,writ}ing drive _" under MS-DOS 6.22, and also somehow interferes with early bootstrap of Windows NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux) appears to make no difference whatsoever, which may help with debugging. + +- The second issue involves + - a WinNT4 disk image + - created by running through a bog-standard NT4 install inside QEMU 2.9.0 + - which will now fail to boot in any version of QEMU - even version 1.0 + - but which VirtualBox will boot fine + - but only if I point VirtualBox at QEMU's raw disk image via a + hacked-together VMDK file + - if the raw image is converted to VHD(X), VirtualBox will also fail + to boot the image with exactly the same error as QEMU + - this state of affairs is not affected by image sparseness (which makes + sense) + +I'm confident I've bisected the first issue. + +I wasn't able to bisect the second issue (as all tested versions of QEMU behaved identically), but I've figured out a working repro testcase and I believe I've managed to pin down a solid root cause. + + + +== #1: Intermittent I/O issues when `-M isapc` is used ===== + +These symptoms sometimes take a small amount of time and fiddling to trigger, but I AM able to consistently surface them on my machine after a short while. (I am very very interested to hear if others cannot reproduce them.) + +So, first of all: + +https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc + (Jul 30 2013): the last version that works + +https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3 + (Oct 30 2013): the first version that intermittently fails + +Maybe lift out and build these branches while reading. *shrug* +(How to do this can be found at the end of this report - along with a time-saving ./configure line, FWIW) + +Here are the changelists between these two revisions: + +https://github.com/qemu/qemu/compare/306ec6c...e689f7c +(Compare direction: OLD to NEW) (Commits: 166 Files changed: 192) + +https://github.com/qemu/qemu/compare/e689f7c...306ec6c +(Compare direction: NEW to OLD) (Commits: 30 Files changed: 22) + +(Someone else more familiar with Git might know why GitHub returns results for both compare directions, and/or if the 2nd link is useful information. The first link returns a lot more results than the 2nd one, at least. Does comparing new>old return deletions?) + +--- + +Now on to the symptoms. In a moment I'll describe reproduction. + +# MS-DOS 6.22 + +The first symptom I discovered was that trivial read and write operations under MS-DOS would sometimes fail: + + C:\>echo test > hi + + General failure writing drive C + Abort, Retry, Fail? + +Anything else that exercises the disk behaves similarly: + + C:\>dir /s > nul + + General failure reading drive C + Abort, Retry, Fail? + +(Note that the above demonstrates both write and read failures) + +(Also, FWIW, `dir /s` == `ls -R`) + +The behavior of the I/O errors is not possible to characterise as it fluctuates so much. For example something as simple as DIR can produce wildly differing results: in one run, poking around with DIR ended with DOS deciding C:\ was empty at one point; at another point in a different run C:\ mysteriously dropped 50% of its contents only to magically gain it all back moments later after some poking around in one of the subdirectories that was still visible. + +The time it takes to trigger these errors is also highly variable. QEMU may fall over as early as hanging forever at "Starting MS-DOS...", or I might get all the way into Windows 3.1 before it triggers (in which case Win3.1 reports vague memory errors - of all things). + +Very occasionally I've seen _SeaBIOS itself_ report "Booting from Hard Disk..." "Boot failed: could not read the boot disk" ... "No bootable device.", and on one occasion I even got "Non-System disk or disk error" "Replace and strike any key when ready"! + + +# WinNT 4 Terminal Server + +Most of the time, NTLDR will fire up normally. But every so often... + + SeaBIOS (version rel-1.7.3-117-g31b8b4e-20131206_080705-nilsson.home.kraxel.org) + + Booting from Hard Disk... + A disk read error occurred. + Insert a system diskette and restart + the system. + +(NB. You're seeing the old SeaBIOS version included with e689f7c, which was the first buggy commit.) + +If NT gets past this point without erroring out (ie, it makes it to the boot menu), the rest of the system is 100% fine and there are no other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to enable disk compression, answer "Yes" to "Compress entire disk now?" and have the process fully complete. No hitches. + +This makes me vaguely recall/wonder that perhaps this could be somehow related to LBA and/or Int 13h, or something floating around near that bunch of functionality. (I'm woefully ignorant about such low-level details.) Perhaps DOS/Win3.1 are stuck using a disk mode that QEMU has a buggy implementation of, while NT 4 (once NTOSKRNL is up and running) is able to use a different disk mode or access mechanism. + +I'm really interested to get some understanding of what the root issue is here, when this is fixed. (I wonder if it's a timing thing?) + +I've observed some unusual behavior with repeated restarts. In one case, I attempted to start NT4 multiple times, and QEMU consistently failed with "No bootable device" each time. So, I removed `-M isapc`, promptly got a boot menu, hit ^C, readded `-M isapc` - and continued to get a boot menu. Yep. I'll accept "really really big coincidence" but I do very much wonder if something else is going on here. I've observed many similar incidents. It makes me wonder whether the contents of memory or some other system state is an influence. Very probably not, but still... + + + +-- Reproduction -------------------------------------------- + +First of all, there was unfortunately no way for me to avoid having to post entire disk images, but I've managed to compress everything down to 174MB total download size. + +FWIW, WinWorld and many other sites seem to have no operational issues providing clear pointers to CD keys; I consider my distribution of my installed HDD images an extension of the apparent status quo. + +That being said, I've put everything on Google Drive so nobody has to headscratch about Launchpad/Canonical/etc's stance on hosting this data. + +So, this folder contains the disk images: https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c ("Download all" at the top-right will create a ZIP file, but FWIW downloading the individual files simultaneously would implement a rough form of download acceleration) + +File meta info: + +Compressed +| +| Apparent +| | Actual +| | | +38M -> 200M (103M) win31.img.xz +82M -> 1G (289M) wnt4ts-broken.img.xz +55M -> 350M (146M) wnt4ts-intermittent.img.xz + +SHA-256s: + +win31: 8179b8180a2ab40bd472e8a2f3fb89fc331651e56923f94ceb9e52a78ee220d2 +broken: a2af5f0bc49a063b75f534b6ffe5b82e32ecc706a64a425b6626feccf6e3fdfa +intermittent: 77ae8c458829ebcdd64c71042012f45d5a2788e6ebd22db9d53de9ef1a574784 + +(Wanted to keep the checksum lines within 80 columns) + +And, since I can't figure out where else in this report to put this, wnt4ts-broken.img's password is "admin" but something seems to have happened to the disk and NT doesn't actually boot properly :(, and wnt4ts-intermittent.img's password is "1234". (These were set up as test images. Now I'm _really_ glad I used simple passwords! :) ) + +--- + + +I have two testcases: DOS 6.22 (+ Windows 3.1), and Windows NT 4. + + +# MS-DOS + +DOS is the simplest. It basically consists of + +$ qemu-system-i386 -drive file=win31.img,format=raw -M isapc -enable-kvm + +And then literally just playing around. Things to try include creating files (`echo blah > file`), repeatedly seeking across the entire FAT (`dir /s > nul` or `dir /s`), and launching Windows (`win`). + +win31.img is not special (as far as I can tell) and merely consists of the result of installing DOS 6.22 and Windows 3.1 from WinWorldPC. I've basically just included the image for convenience. + +Generally no single "run" is immune to starting Win3.1 and then launching File Manager; if that doesn't generate an error, something is definitely up. + +The second best trigger is creating new files. That very very frequently produces "General Failure ...", but not always. + + +# WinNT 4 + +Windows NT 4 is a bit more complicated. Because this error only occurs at presumably a single small point very early in boot, the window of opportunity for the glitch to surface within is much much narrower and thus often requires a larger number of tries. + +Anecdotally I've had QEMU hit the boot error at the first try/run, and after as many as 63 "successful" boots. + +I made a small test harness that automates the launch process. It consists of two shell scripts and requires tmux (and netcat). (*Potential epilepsy warning*: if you use a light-colored terminal background, the terminal QEMU is repeatedly invoked from will continuously flash rapidly from white to black.) + +One of the scripts is run inside a tmux session in one terminal, while the other script is run in its own terminal (without any tmux). + + +I named this one `run-qemu-loop`: + +--8<-------------------------------------------------------- + +#!/bin/bash + +# --- + +qemu=/path/to/qemu-system-i386 +#or, alternatively: (I used the following line myself so I +#could tab-complete my way to different qemu executables) +#qemu="$1" + +disk=/path/to/wnt4ts-intermittent.img + +# --- + +port=4444 + +rm -f STOP itercount + +itercount=0 + +while :; do + + [ -f STOP ] && break + + ((itercount++)) + echo $itercount > itercount + + $qemu \ + -enable-kvm -vga cirrus -curses -M isapc \ + -drive file="$disk",format=raw \ + -chardev socket,id=mon0,host=localhost,port=$port,server,nowait \ + -mon chardev=mon0,mode=readline + + #point to an otherwise-unused terminal if you like (see also: `tty`) + #echo "$itercount run(s)" > /dev/pts/__ + +done + +------------------------------------------------------------ + +Not much logic above; this just repeatedly runs QEMU for as long as +the file `STOP` does not exist in the current directory. + +The key "magic" bit is that QEMU is launched in -curses mode. + +The other key bit is that the above script is run inside tmux. + + +Here's `tmux-ctl-loop`: + +--8<-------------------------------------------------------- + +#!/bin/bash + +port=4444 + +tmux=./tmux + +printf -v l '%0.0s-' {0..25} +h1="$l/ buffer dump begin \\$l" +h2="$l-\\ buffer dump end /-$l" + +while :; do + + while :; do + echo | nc localhost $port -q0 -w1 > /dev/null && break + echo 'Start qemu!' + done + + buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" + + echo "$h1" + [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' + echo "$h2" + + if echo "$buffer" | grep -q 'A disk read error occurred.'; then + + s="<Crashed after $(< itercount) runs.>" + echo "$s" + echo "$s" >> stats + + touch STOP + + #echo q | nc localhost $port -q0 > /dev/null + + exit + + elif echo "$buffer" | grep -q 'OS Loader V4.00'; then + + echo '<Booted successfully, trying again>' + + echo q | nc localhost $port -q0 > /dev/null + + else + + echo '<Waiting for boot>' + + fi + +done + +------------------------------------------------------------ + +Nothing particularly amazing going on here either. + +While `qemu-run-loop` is running inside tmux in the first terminal, this is running in the 2nd one. + +The small infinite loop at the top only breaks when it can successfully ping QEMU and it knows it's running. + +Then, a screendump of the contents of the terminal QEMU is in is fetched from tmux, and the buffer's content is analyzed. + +- If NTLDR fails, the script creates `STOP` to halt qemu-run-loop, + sends `q` to QEMU through netcat, and then the script exits. + +- If NTLDR loads successfully, the script sends `q` to QEMU and continues + looping. (qemu-run-loop will not find the `STOP` file, and so restart qemu.) + +The scripts run very quickly, with 2-3 iterations per second on my i3 box. + + + +# Usage + +Save the two scripts above to the same directory as wnt4ts-intermittent.img, +then: + +- (If port 4444 doesn't work, the value needs to be changed in both scripts.) + +- In the first terminal, run `tmux -S <file>`, where <file> names the socket + tmux will use. This needs to match "tmux=" at the top of `tmux-ctl-loop`. + (with `tmux=./tmux`, the command would be `tmux -S tmux`) + +- Still in the first terminal (and now also inside tmux), enter + `./qemu-run-loop`, passing the path to qemu if you're using that approach + (refer to the first few lines of the script). Don't hit enter yet. + +- Now, in the 2nd terminal, type `./tmux-ctl-loop` + +- Hit enter in both terminals. + + +Rationale for timing of Enter key: + +- Running qemu-run-loop first will start QEMU, and if NTLDR starts + successfully it will immediately begin counting down from 30. If NT actually + starts to boot and is then hard-shut-down this /may/ affect the disk image + +- tmux-ctl-loop will annoyingly spam a continuous stream of 'Start qemu!' until + qemu-run-loop is running. + +- Starting both scripts at "more or less" the same time (no rush) works out + well. + + +Hopefully potential script modifications are obvious; for example + +- changing tmux-ctl-loop to not send 'q' to qemu so you can connect to the HMP + yourself + (NB, if `STOP` is not created, when qemu finally exits it will of course + promptly be relaunched) + +- pointing run-qemu-loop to a modified qemu binary + + + +== #2: QEMU-vs-VirtualBox image issue ====================== + +I was initially completely stumped by this issue, perhaps unsurprisingly so. :) + +wnt4ts-broken.img is a perfectly ordinary NT 4 installation that was created in QEMU 2.9.0. I created a 1GB disk with `truncate`, picked NTFS and installed everything (which took a while). + +NT setup reboots a number of times during the boot process, and IIRC those all went just fine. However, at some point, the image began to consistently bomb out with "A disk read error occurred. ...", and stubbornly refused to boot, regardless of the number of boot attempts I tried. + +QEMU 2.0.0, 1.5.0, and 1.0 (the earliest version I was able to build on my system) all consistently hit "disk read error occurred". + +I tried compiling QEMU 1.0 using clang so I could build for 32-bit on my 64-bit system (GCC 7 died with "Frame pointer required, but reserved"). The resulting qemu completely crashed if I didn't enable KVM (ie, TCG was (understandably) broken); with KVM enabled qemu didn't crash, but NTLDR halted with the same error as on 64-bit qemu. (TL;DR, no difference whatsoever.) + +My initial reaction at this point was to try the image on another virtualization platform. My first pick was VirtualBox. + +So, I followed the official instructions for pointing VirtualBox to physical disk images, except I substituted a /dev/loopN device I'd pointed to the image file via losetup. + +And... VirtualBox picked the image up fine and Just Worked(TM). Yay! - but not yay. What gives?! + +Confused, I then tried to convert the disk image to VHD format. Unfortunately, for some reason, if I try `qemu-image convert ... -O vhdx ...`, VirtualBox chokes on the result: + +----- + +VD: error VERR_NOT_SUPPORTED opening image file +'/.../wnt4ts-broken-qemuconv.vhd' (VERR_NOT_SUPPORTED). + +Result Code: NS_ERROR_FAILURE (0x80004005) +Component: MediumWrap +Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda} +Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945} +Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001) + +----- + +Welp. + +Well, a bit more digging later, and I found I could do + +$ VBoxManage convertfromraw wnt4ts-broken.img wnt4ts-broken.vhd + +but... as soon as I pointed VirtualBox to this, it too began to choke with "A disk read error occurred". + +And yet, the VMDK->raw image setup worked just fine. + +I found I could even replace the loop device with the path of the .img file itself and that worked just fine too. + +At my wits' end, I followed some online instructions to learn about manual CHS configuration so I could try and get the image working in Bochs. "A disk read error occurred". I wasn't surprised. + +It was at this point I began to give up, but I decided to try One Last Thing(TM) before properly throwing in the towel. + +:) + +I decided to learn a bit more about how `VBoxManage internalcommands createrawvmdk` worked, and try one thing in particular: I can edit the .vmdk file, but can I point `createrawvmdk` at the .img file directly too? + +Turns out, yes you can. + +It also turns out that this promptly caused VirtualBox to bomb out. + +Interesting. + +For reference, here's the VMDK file I initially created (by pointing `createrawvmdk` at /dev/loopN) and then later edited to point straight to the .img file, with both approaches resulting in successful boot. + +--8<-------------------------------------------------------- + +# Disk DescriptorFile +version=1 +CID=e35b9a45 +parentCID=ffffffff +createType="fullDevice" + +# Extent description +RW 1536000 FLAT "/absolute/full/path/to/wnt4ts-broken.img" 0 + +# The disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.adapterType="ide" +ddb.geometry.cylinders="1523" +ddb.geometry.heads="16" +ddb.geometry.sectors="63" +ddb.uuid.image="871a6044-c8ca-48ed-b7aa-e6fc49da3db4" +ddb.uuid.parent="00000000-0000-0000-0000-000000000000" +ddb.uuid.modification="3661715c-3906-4e4a-ab65-486d140e03b8" +ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000" +ddb.geometry.biosCylinders="761" +ddb.geometry.biosHeads="32" +ddb.geometry.biosSectors="63" + +------------------------------------------------------------ + + +Here's the _diff_ of what happens if I point `createrawvmdk` at wnt4ts-broken.img directly: + +--8<-------------------------------------------------------- + +ddb.geometry.cylinders="2080" +ddb.geometry.heads="16" +ddb.geometry.sectors="63" + +------------------------------------------------------------ + +:D + +Naturally, + +$ qemu-system-i386 -drive file=wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 -M isapc -sdl + +will boot happily on 2.9.0 (notwithstanding the occasional "disk read error occurred" documented above). + +It will also boot in 1.6.0. + +(POTENTIAL BUG HEADSUP: 1.0 and 1.5.0 both lock up with a blank 640x480 window and use 0% CPU if I specify `-M isapc`.) + +And, of course, using these CHS values in Bochs also results in successful boot as well (after setting the CPU type to pentium). + +Unfortunately, I have no idea what sequence of events caused the creation of the VMDK file above. No invocation of `createrawvmdk` is producing a VMDK file with the CHS settings above. + +I've only just begun to learn about the intricacies of CHS. Am I to understand that these values are stored amongst the first 512 bytes of the disk? If this is the case, then I wonder what changed the data, and why. I was initially only using QEMU 2.9.0, and didn't move the image to different VMs or QEMU versions. Perhaps Windows NT got confused about the disk CHS and rewrote it? + + +== Sporadic BIOS-level boot failure ======================== + +I have multiple screenshots of SeaBIOS in QEMU 2.9.0 halting with "No bootable device" (et al), even with the above manually-applied CHS settings. + +Commit e689f7c also presents such errors. + +Commit 306ec6c does not suffer from intermittent breakage of any kind: + +- No SeaBIOS flake-outs +- No "Non-system disk or disk error" +- No "A disk error has occurred" +- No "General failure ..." + +While most of my confidence in commit 306ec6c is based on anecdotal evidence, I modified `tmux-ctl-loop` a little to soak-test BIOS-level I/O stability and left this modified version running for a few minutes. + +--8<-------------------------------------------------------- + +#!/bin/bash + +port=4444 + +tmux=./tmux + +printf -v l '%0.0s-' {0..25} +h1="$l/ buffer dump begin \\$l" +h2="$l-\\ buffer dump end /-$l" + +while :; do + + while :; do + echo | nc localhost $port -q0 -w1 > /dev/null && break + echo 'Start qemu!' + done + + buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" + + echo "$h1" + [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' + echo "$h2" + + if echo "$buffer" | grep -q 'Non-system disk' || echo "$buffer" | \ + grep -q 'No bootable device' + then + + s="<Hit error after $(< itercount) runs.>" + echo "$s" + echo "$s" >> stats + + touch STOP + + #echo q | nc localhost $port -q0 > /dev/null + + exit + + elif echo "$buffer" | grep -q 'OS Loader V4.00' || echo "$buffer" | \ + grep -q 'A disk read error' + then + + echo '<Boot did not hang at BIOS, trying again>' + + echo q | nc localhost $port -q0 > /dev/null + + else + + echo '<Waiting for boot>' + + fi + +done + +------------------------------------------------------------ + +For the above to work, the top of run-qemu-loop must also be modified to read something along the lines of + +disk=/path/to/wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 + +(Suggestion: modify copies of both scripts) + +One small terminal-flicker-headache (and a 57°C CPU) later, I was able to carefully observe just over 350 successful runs in which QEMU commit 306ec6c only ever produced a boot menu. No other hitches. + +** Important: ** + +However, commit 306ec6c will fail to boot, ever, if the cylinders and geometry are not set to the values VirtualBox "discovered". (Of note is the fact that QEMU (2.9.0) was what initially created this image. I must admit that I don't remember what sequence of QEMU versions I fed the image to - and I maybe, possibly, didn't think to back the file up (sorry), so maybe something mangled something somewhere. But VirtualBox figured it out nonetheless!) + +Furthermore, feeding /dev/loopN to any QEMU version will NOT result in correct CHS discovery (and successful boot). + +This is what leads me to conclude that I've discovered two separate issues. + + + +== Appendix: How to build the branches ===================== + +It's very simple. + +First, `git clone https://github.com/qemu/qemu` somewhere if you don't already have a local copy. If you have an old git checkout that's from 2014 or later, you can use that old checkout instead. (If you want to test an old checkout you have, the commands below will either work perfectly or completely bomb out with no side effects.) + +A full checkout is a ~183MB download. Sorry. + +Next, create two new directories somewhere. Name them what you like, eg `qemu-working` and `qemu-broken`. + +Now, cd into the checkout directory, and run: + +$ git archive 306ec6c3cece7004429c79c1ac93d49919f1f1cc | tar xC /path/to/qemu-working/ + +$ git archive e689f7c668cbd9d08f330e17c3dd3a059c9553d3 | tar xC /path/to/qemu-broken/ + +The paths can be relative. + +Now, run this in both of the new directories: + +$ ./configure --python=python2.7 --disable-libssh2 --disable-seccomp --disable-usb-redir --disable-guest-agent --disable-libiscsi --disable-spice --disable-smartcard-nss --disable-vhost-net --disable-docs --disable-attr --disable-cap-ng --disable-vde --disable-user --disable-bluez --disable-vnc-ws --disable-xen --disable-brlapi --enable-debug --target-list=i386-softmmu --disable-fdt + +$ make -j64 + +You can open two terminals and configure and build both simultaneously if you like. + +On my decent but very basic (2-core+HT) i3 box, -j64 actually works out - make doesn't actually launch too many gcc processes. You *will* see your system load spike to ~20 though :) +(NB. Do. not. use. -j64. with. the. linux. kernel.) + +On my system, a single build with -j64 takes only about 35 seconds. C FTW. (Although this has increased to 1min20sec for more recent builds.) + +Most of the configure arguments remove functionality I'll never use (in this situation) and which will only slow down the build. + +Once QEMU is built, run qemu-system-i386 directly from where it has been built. + +$ /path/to/qemu-working/i386-softmmu/qemu-system-i386 ... +$ /path/to/qemu-broken/i386-softmmu/qemu-system-i386 ... + +Again, the paths can be relative. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1745316 b/results/classifier/accel-gemma3:12b/vmm/1745316 new file mode 100644 index 000000000..66cfecbca --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1745316 @@ -0,0 +1,175 @@ + +SDL1.x>SDL2 regressions: non-usbtablet mouse position reporting is broken, and VGA/compatmonitor/serial/etc view switching is unusable + +Hi, + +I almost exclusively use -sdl when I use QEMU. The GTK UI (I'm on Linux) distinctly takes a few extra seconds to start on every boot, and I don't really ever use the extra controls it provides. I hope the SDL-based UI never goes away :) + +The SDL 1.2 > SDL 2.0 update (committed between June 8-20 2017) introduced the following two regressions: + +- PS/2 and serial mouse position reporting became completely broken (only usbtablet works) + +- The compatmonitor/serial/parallel "views" try to open new windows, which does not play well on my system at all + +First of all, here are the bisection details: + +https://github.com/qemu/qemu/commit/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b + (June 8 2017): the last version that works + +https://github.com/qemu/qemu/commit/7e56accdaf35234b69c33c85e4a44a5d56325e53 + (June 20 2017): the first version that fails + +Here are the changelists between these two revisions: + +https://github.com/qemu/qemu/compare/269c20b...7e56acc +(compare direction: OLD to NEW) (Commits: 60 Files changed: 85) + +https://github.com/qemu/qemu/compare/7e56acc...269c20b +(compare direction: NEW to OLD) (Commits: 41 Files changed: 108) + +(Someone else more familiar with Git might know why GitHub returns results for both compare directions. I'm including both links just in case.) + +I've found that configuring commit 7e56acc using --with-sdlapi=1.2 completely remedies all issues. Thus, I think the issue is with SDL 2. + +== #1: Broken mouse position reporting ===================== + +This surfaces immediately with older operating systems. I first experienced it when trying to install OS/2 for the first time, and thought there was something wrong with OS/2. Then I experienced the same issues in Windows 3.1 and MS-DOS applications and I knew something was up with QEMU. + +In a nice coincidence, I've recently been playing around with prehistorically ancient Linux systems, and while looking around a Linux 0.99-based SLS system from 1992 I discovered a low-level (console) mouse-testing utility buried in /usr/X386. This utility only works when I configure QEMU to use a serial mouse, but it reveals some very interesing data: the dx and dy values ("d" = "delta", right?) received by the kernel do not contain relative values such as -1, -10, 2, 5, etc, but instead absolute values such as 0, 12, 37, 112, 329, etc. + +Similarly, if I configure Windows 3.1 to use a serial mouse, the mouse position jumps exponentially around the screen relative to my mouse movements (it's very hard to control), consistent with delta values being reported as absolute instead of relative. + +I found that the DOS CuteMouse driver comes with a mouse-testing program. CuteMouse absolutely refuses to detect QEMU's serial mouse for some reason (?!), but when QEMU is running in PS/2 mode, the mouse tester that comes with CuteMouse reports that the mouse at 632,192 no matter how much I move the mouse around the window. If I look carefully I can see the DOS cursor flickering back and forth as I move the mouse and the tester rewrites the line showing the position info, so I don't think the test program is broken. + +I got curious and wondered if this was actually an internal SDL bug. However, the following test program reports perfect values for me: + +--8<-------------------------------------------------------- + +#include <stdio.h> +#include "SDL2/SDL.h" +int main(void) { + SDL_Init(SDL_INIT_VIDEO); + SDL_Window *window = SDL_CreateWindow("Mouse test", + SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, + 640, 480, SDL_WINDOW_RESIZABLE + ); + if (window == NULL) { + perror(SDL_GetError()); + exit(1); + } + for (;;) { + SDL_Event event; + while (SDL_PollEvent(&event)) { + if (event.type == SDL_MOUSEMOTION) { + printf( + "x=%d y=%d xrel=%d yrel=%d\n", + event.motion.x, event.motion.y, + event.motion.xrel, event.motion.yrel + ); + } + if ( + event.type == SDL_KEYDOWN || + event.type == SDL_QUIT + ) { + SDL_DestroyWindow(window); + SDL_Quit(); + exit(0); + } + } + } +} + +(gcc ... -lSDL2) + +------------------------------------------------------------ + +Unfortunately it would seem the issue is QEMU-specific. + +--- + +Finding modern test targets to verify mouse functionality with was actually a small challenge. I tested Ubuntu, Lubuntu and even GParted, but the recent Linux kernels in all three systems automatically loaded the usbtablet module early in the boot process, completely hiding the bug. + +I've found two actively-maintained somewhat-mainstream platforms that make for good tests. These are both ISOs: + +- ReactOS: + - http://www.reactos.org/download + - pick "Download LiveCD" and then "proceed with the download" at + bottom-right of popup + +- Tiny Core Linux: + - http://distro.ibiblio.org/tinycorelinux/downloads.html + - pick TinyCore (16MB) + +ReactOS is a very good example, as it's actively maintained and is probably heavily tested in QEMU (albeit apparently without SDL(2)). + +Tiny Core is a bit of a mixed bag. It's actively maintained and uses a recent kernel (without usbdevice). It also uses a resurrected low-memory XFree86 target that was officially dropped decades ago for its graphics (and mouse input). It could be argued that Tiny Core's mild obscurity makes it an even better test target. + +--- + +I've attached to this report the mouse test utilities I've played with. Both are faster to iterate with than waiting for Tiny Core or ReactOS to boot. + +----- FreeDOS + CuteMouse + mousetst ----- + +This boots completely and is ready to look at the mouse position in around a second. It automatically starts the mouse tester on startup and APM-shuts-down QEMU when you exit the mouse tester with ESC. I can highly recommend this version for iteration/verification. + +$ qemu-system-i386 -fda freedos-mousetest.img +$ qemu-system-i386 -fda freedos-mousetest.img -sdl + + +----- Linux-0.99 (SLS) + 'mouse.c' ----- + +This is a heavily stripped-down SLS configuration containing just the mouse testing utility. + +$ qemu-system-i386 -boot a -fda sls-boot.img -hda sls-mousetest.img \ + -serial msmouse + +$ qemu-system-i386 -boot a -fda sls-boot.img -hda sls-mousetest.img \ + -serial msmouse -sdl + +Login as root (no password), and then + +# ./mouse Microsoft /dev/ttyS0 + +Also, the following produces junk results, but I'm including it because it may be interesting anyway: + +$ qemu-system-i386 -boot a -fda sls-boot.img -hda sls-mousetest.img -sdl + +and + +# ./mouse Microsoft /dev/ps2aux + +The reason I think this is noteworthy is that the button state affects the reported values (incorrectly, but they do still change), but moving the mouse does not. So while the interpretation is wrong, the behavior seems to be similar to that reported by CuteMouse's mouse tester. (Unless the position fields are being perfectly skipped over.) + +When you're done with this image - `halt` takes several seconds and there's really no point. Just closing QEMU manually is faster. (This is also why I used the shorter -[hf]da syntax - writes to the disk images are not relevant.) + +(Also - since I can't possibly leave this info out :) - http://www.oldlinux.org/Linux.old/distributions/SLS/, `sls-1.0.tar.bz2`. This is a turnkey disk image that Just Works(TM). `boot.img` attached below is in fact the same as `a.img` in this archive.) + +--- + +In case it's useful, I included a Windows 3.1 test image when I reported https://bugs.launchpad.net/qemu/+bug/1745312. This image (which happens to be configured for PS/2) can be found in this folder: https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c + +For reference: this image includes a lot of cruft as it's an active test image I've used for a lot of different things. It contains a full copy of the contents of the Win3.1 installation disks in W31INST. You can `deltree c:\windows` and reinstall by running `setup` in that directory (takes 3-5 minutes), or `subst a: c:\w31inst` before starting Windows and you'll be able to use Windows Setup to switch to a serial mouse. + +== #2: SDL view switching unusability ====================== + +This issue is (somewhat) more straightforward to demonstrate. Simply + +$ qemu-system-i386 -sdl + +and then hit CTRL+ALT+2 (or 3 or 4). + +On my system, when I do this, QEMU creates and destroys new windows in an infinite loop for as long as I have CTRL+ALT+n held down. I have to hit `2` really quickly! + +I've also observed that some internal contention can frequently cause the compatmonitor window to become blind to the Enter key. It seems to be that this occurs most often when the windowmanager I'm using (tested using i3 and openbox) has focus-follows-mouse enabled and the mouse is over the area of the screen where the compatmonitor window opens itself. Perhaps this is caused by the CTRL+ALT capture code interacting badly with window focus state? (I'm very very interested to hear if you cannot reproduce this.) + +I initially thought all of these changes/glitches were due to some kind of messed-up "upgrade" / deliberate feature that happened to be broken on my system. But the only (obviously-)UI-related tasks I found in the changelist above just mention upgrading SDL, with no particular UI work (that I can see). It looks like this is actually an SDL thing - unless some (preparatory?) changes occurred in QEMU before the commit window I discovered. I have no idea. + +A couple things about fixing this that I want to mention: + +The way the GTK UI does things, views can be switched inside the same window, or they can be detached into new windows. This provides the best of both worlds - and there are situations where I do want both behaviors. + +If QEMU is not averse to burying an obscure option somewhere that lets me pick whether SDL will open views in new windows or the same window, that could be very nice - and it would bring the SDL UI to perfect feature parity with the GTK UI, too. But I'm not sure what QEMU's stance on obscure options is. + +That said, my preference for the SDL 1.x way of doing things is admittedly very probably biased by the usability issues created by this bug. Incidentally, I've taken to using `-serial null -monitor stdio`. But for that to work I have to remember to add it ahead of time, and I do often forget, heh. + +I'll be very interested to play with QEMU view switching once this is less glitchy. If the fixed implementation still opens new windows, I'll see what I think of that once it works stably. :) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1746943 b/results/classifier/accel-gemma3:12b/vmm/1746943 new file mode 100644 index 000000000..d3b23ecdc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1746943 @@ -0,0 +1,11 @@ + +qemu-aarch64-static: qemu: uncaught target signal 11 for ps/top cmd + +In a docker container created from an aarch64 image, injects qemu-aarch64-static (in /usr/bin) + run ps/top cmd inside this container + + reports "qemu: uncaught target signal 11 (Segmentation fault)" + +Tried qemu-aarch64-static from fedora 27 / ubuntu artful / debian unstable (i.e. qemu version 2.10 - 2.11) + +The aarch64 dock image is fedora 27(and with qemu-aarch64-static Fedora 27), hence I opened a related bug here https://bugzilla.redhat.com/show_bug.cgi?id=1541252 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1749016 b/results/classifier/accel-gemma3:12b/vmm/1749016 new file mode 100644 index 000000000..e4443e3e3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1749016 @@ -0,0 +1,38 @@ + +VHDX BAT and Metadata Region Header Required Bit Not Set + +When converting a VMDK to VHDX the resulting VHDX's Region table has a small error. According to the VHDX specification the BAT and Metadata entries for the region header required bit should be set to 1. In a VHDX created by qemu-img, this bit is not set. + +See Table 4: Known Region Properties of the VHDX specification. + +The structure format is as following from Structure 4: Region Table Entry: + +struct VHDX_REGION_TABLE_ENTRY { +GUID Guid; +UINT64 FileOffset; +UINT32 Length; +UINT32 Required:1; +UINT32 Reserved:31; +} + +The Required bit for VHDX specified BAT and Metadata Regions Required bit in the entry is not set as required in the current specification. + +VHDX Region Table in a valid VHDX + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 01 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 01 00 00 00 + +VHDX Region Table in a VHDX converted by qemu-img from VMDK + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 00 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 00 00 00 00 + +The fist bit at 0x0003002A and 0x0003004A should be set to 1. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1750899 b/results/classifier/accel-gemma3:12b/vmm/1750899 new file mode 100644 index 000000000..1ca30c3f8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1750899 @@ -0,0 +1,25 @@ + +Mouse cursor sometimes can't pass the invisible border on the right side of the screen + +I'm using qemu 2.11 on Gentoo Linux, with configured GPU passthrough (Radeon RX580) to the guest Windows 10. +This configuration is alive for last 4 years, this time I changed a lot qemu, linux kernel and windows versions, changed GPU and always all was working as expected. I always used standard PS/2 mouse emulation and that was enough for me. + +Now, I bought two new monitors, instead of old one, and setup them as one logical monitor, using technology called Eyefinity - it's a part of standard Radeon software. Now Windows thinks, that I have one monitor with resolution 2160x1920 (I bought Dell monitors with a thin borders and use them in portrait mode). + +Windows uses it without any problems, but mouse become crazy - sometimes (~3 times from each 5) I can't move cursor to the right border of the screen, it looks like the invisible vertical border. I spent really huge amount of time to understand, which component is the root of problem and found, that it's really a mouse. I tried all possible variants (standard, tablet, virtio-mouse-pci, virtio-tablet-pci), and found, that in both mouse variants bug is reproducing, and in both tablet variants - cursor stuck near all real borders and corners, so it's not a variant too. +The only working variant becomes passing real USB port to my VM and insert second mouse to this port. So, now it's working, but I have two mice on my working place, which doesn't seems very useful. + +Here is my command line: + +QEMU_AUDIO_DRV=pa QEMU_PA_SAMPLES=4096 qemu-system-x86_64 -enable-kvm -M q35 -m 12168 -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ +-bios /usr/share/qemu/bios.bin -rtc base=localtime -vga none -device secondary-vga \ +-drive id=virtiocd,if=none,format=raw,file=/home/akushsky/virtio-win-0.1.141.iso \ +-device driver=ide-cd,bus=ide.1,drive=virtiocd \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=05:00.0,bus=root.1,addr=00.0,multifunction=on,romfile=/opt/kvm/images/Sapphire.RX580.8192.170320_1.bin,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive file=/dev/sdb,id=disk,format=raw,if=none,discard=on,cache=none,aio=native,detect-zeroes=unmap -device scsi-hd,drive=disk,id=scsi0 \ +-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-usb -usbdevice host:046d:c52b + +All in all, I checked on Windows 7 and Windows 10, and on qemu 2.10 and 2.11 - bug is always reproducible. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1751264 b/results/classifier/accel-gemma3:12b/vmm/1751264 new file mode 100644 index 000000000..67e97718e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1754656 b/results/classifier/accel-gemma3:12b/vmm/1754656 new file mode 100644 index 000000000..e33ae142a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1754656 @@ -0,0 +1,162 @@ + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM + +Version: + +QEMU emulator version 2.11.1 + +Introduction: + +This is call for action to get attention of somebody in QEMU project/organization, who is capable of actually doing something about this pressing issue. This might be TLDR for some, but that's only because of the complexity of the issue. Please read this with open mind. + +Problem: + +As QEMU users, we need (it is a requirement) to have some mechanism in place, to somehow convert simple POSIX signal sent form host, into graceful ACPI shutdown of the guest. This signal, due various historical reasons and daemon design, must be SIGTERM foremost. + +Status quo: + +After wading through mailing lists and bug tracker I concluded that this is "political" problem and I am in search of somebody, a "politician" within QEMU project, who will help us reach conclusion to this problem. + +First I will present analysis of the situation, and then propose some suggestions for solutions. + +Even then, any of these proposals might be, potentially, seen as problematic in eyes of QEMU maintainers, developers, dictators, long term users or their dogs. + +That's why we need somebody willing, "higher up the chain" or whatever, to orchestrate discussion so that we can actually reach consensus in the matter, solution that is acceptable to **everyone**. + +Analysis: + +Each QEMU emulated virtual machine (vm), running in the host system, is represented by single qemu-* process (followed by several threads). Thus for all intents and purposes, any such instantiated vm, must be seen as it's own, separate, daemon. + +I repeat running qemu-* vm **is a daemon**. + +QEMU provides incredible IO redirection capabilities, so we don't need to get into issues of logging, console and monitor redirections and such, as this is already a (perfectly) solved problem. + +What we cannot currently do, at least easily, reliably and simply, is to shutdown guest gracefully from "outside". + +That is not a problem for those of us, who use some kind of higher level orchestrator (I think one of them is virsh, but this is not important in this matter) that takes care of this by communicating with QEMU directly (I guess this is done by sending commands to internal monitor by pipe (or socket) held open by mentioned orchestrator). + +However it is a problem for those of us, who run qemu-* processes bare or supervised. + +Let's say I, as administrator, want to implement vm instance as supervised service. +I can use any supervisor for that, systemd even. Let us not get into into supervisor wars. + +At basic level almost all supervisors are similar. Supervisor usually is yet another process, that "leads" the qemu-* one. + +In case of systemd it is PID1, but in case of other supervision schemes, like daemontools, runit, s6 or nosh, it is separate '*supervise' process instead. + +When such supervisor is tearing down the service, "leading"/supervising, parent will send SIGTERM to it's child qemu-* process. + +This behaviour is almost universal among all supervisors. This due the fact, that it is customary for daemons to cease all operations and exit cleanly when receiving SGITERM signal. If daemon child fails to exit within configurable timeframe, supervisor deals with it by the means of SIGKILL. + +As such, one would expect, similarly, for qemu-* process to send ACPI shutdown event to guest internally (roughly equivalent to 'system_powerdown' monitor command) on SIGTERM reception. + +But this is not what happens! + +Instead, qemu-* just flushes pending IO and kills the guest instantly. + +Then, on next vm "boot", guest detects this as power failure event, and performs fsck checks and other things, it is supposed to do in case of power failure. We are not mentioning possible data loss that might have happened due to this behavior, either. + +Some supervisors (like systemd for example) might provide feature to change "termiante operations" signal to something else like SIGTERM, but that is not universal supervisor feature by any means. Default action for any proper daemon is to cleanly terminate on SIGTERM. + +That is why we need ability to somehow instruct QEMU to **always** perform graceful ACPI shutdown on SIGTERM. + +Potential reply to this bug saying that one should send 'system_powerdown' over monitor connection won't fly! + +As it is not always possible (nor required) to hook into supervisor's signal processing (main reason being intentional supervisor simplicity in search of extreme reliability, and de facto standardized behavior of daemons to exit cleanly on SIGTERM). + +More over, in situations like machine reboot, most supervisors won't play around with signal remapping, they will simply send out SIGTERM to all supervised processes. We want our qemu-* instances to come up undamaged from such action (on next host reboot) and not have them stuck in fscks (or worse - ending up damaged) . + +If this can be extended further, inside QEMU, with internal signal to action remapping, the better, but supporting graceful shutdown on SIGTERM is hard requirement. + +Proposed solutions: + +0. modify QEMU so that it emits ACPI shutdown event equivalent to 'system_powerdown' monitor command by default + - this seems to be a "no go", with backwards compat. and "current users expectations" + cited as the reasons + - I won't go into a fact that QEMU changed option handling without BOLD notice few times + +1. add single switch '-graceful-shutdown-on-sgiterm' + - this was rejected when person tried to submit patch implementing something similar + to what I am requesting, only bound to SIGHUP + - that person (implementing graceful poweroff on SIGHUP) was wrong, almost no + supervision scheme in existence sends out SIGHUP on service termination request, + although all supervisors are able to send out SIGHUP when instructed + - in daemons SIGHUP is usually reserved for "daemon reload" which can be interpreted + like "reboot" in QEMU context + - if we see qemu-* proces for what it is, a daemon, it must react properly to SIGTERM foremost + +2. add ability to map internal monitor action commands to few signals like SIGTERM, SIGHUP, SIGINTR, SIGUSR1, SIGUSR2, SIGALARM etc + - this seems like best solution to me, that allows us to satisfy both + backwards compat. and "current users" requirement, yet allows us + to use qemu-* with proper supervision, and it even adds something extra + (I know some of these signals are used internally by QEMU) + - QEMU already has options parsing infrastructure in place to handle this nicely, something like: + : -signal SIGTERM,monitorcommand=system_powerdown -signal SIGHUP,monitorcommand=system_reset + would be great in this case + +3. add ability to map signals to executable scripts + - with this scheme QEMU would spawn child on signal reception, and this + script would then be used to perform the action + - this solution is most complex, most convoluted and most "flexible" + - for example with definition like this: + : -signal SIGTERM,script=signals/sigterm + qemu would perform this sequence of tasks: + - on SIGTERM qemu-* would spawn child script ./signals/sigterm + - this script would then pull out monitor fd descriptor from some kind of fd holder + - would write 'system_powerdown' command into monitor fd and terminate + - qemu-* would then read the command from monitor + - qemu-* would then interpret read-in command and gracefully terminate + - option parsing infrastructure is in place and QEMU is able to spawn and reap it's own children + which is proven by network up/down scripts + + +Of these, it seems that 0. and 1. are simplest to implement, yet "politically" unimplementable. + +More over QEMU people seem to be hard set on SIGTERM meaning "killing unresponsive guest". + +2. seems like most reasonable proposal that has potential to make everyone happy. It is also most reliable because internal QEMU command dispatch would have least chances to fail. + +3. is most flexible and can also be combined with 2. Reliability wise, there is slight chance signal handling script will fail to execute, leaving qemu-* at the mercy of supervisor (timeouted SIGKILL). + +Both 2 and 3 should probably provide configurable timeout after which QEMU would perform default action (eg. as it does now). + +Conclusion: + +I hope QEMU project members understand severity of the issue and are open to listed solutions. It might be that proposed solutions don't match QEMU project "spirit" perfectly. If so, I urge people capable of resolving this, to propose their versions. + +The fact is, that with proliferation of systemd, popularity of alternative supervisors is on the rise as well, but even under systemd, unintuitive handling of SIGTERM by bare QEMU processes is a problem. + +Further Reading: + +https://patchwork.kernel.org/patch/9626293/ + + - Daniel P. Berrange says: + "Because QEMU already designate that as doing an immediate stop - ie it'll + allow QEMU block layer to flush pending I/O, but it will not wait for the + guest to shutdown. If we change that behaviour we'll break anyone who + is already relying on SIGHUP - qemu might never exit at all if the guest + ignores the ACPI request" + + - this behaviour is incorrect if we perceive qemu-* process as daemon, proper, + yet it is, supposedly, entrenched in QEMU userbase + - signals remapping capability would allow us to keep the "old" behavior for entrenched users + while it would allow administrators and orchestrator writers to select signal disposition + they actually need + +https://bugs.launchpad.net/qemu/+bug/1217339 +and +https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html + + - on my QEMU version of 2.11.1 SIGTERM just kills the guest without proper shutdown + - although thread says exit is graceful + - dicussion is problematic in several ways: + - SIGTERM is not intended to "terminate unresponsive guest" eg "terminate daemon uncleanly" + in any sane daemon in existence + - it means "terminate gracefully" + - if "terminate unresponsive guest" was true meaning of SIGTERM, databases like + mariadb or postgers would kill themselves on SIGTERM, leaving data in + inconsistent state, which they, of course, do not! + - some kind of "signal tapping" similar to "port tapping" is suggested + - this is non-obvious and error prone and nonstandard (no normal supervisor + will play such signal tapping games) + - signal remapping makes more sense in this regard \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1758 b/results/classifier/accel-gemma3:12b/vmm/1758 new file mode 100644 index 000000000..f468a20b9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1758 @@ -0,0 +1,13 @@ + +libssh missing on macOS/m1 +Description of problem: +I did a "git pull" in my source for qemu. Now when I do "make" I get: +../block/ssh.c:27:10: fatal error: 'libssh/libssh.h' file not found + +Am I supposed to install libssh separately? I were able to compile qemu about a month ago or so. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1759337 b/results/classifier/accel-gemma3:12b/vmm/1759337 new file mode 100644 index 000000000..2ab3d3eb4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1759337 @@ -0,0 +1,17 @@ + +'Failed to get "write" lock' error when trying to run a VM with disk image file on an SMB share + +This has been reported and discussed downstream: + +https://bugzilla.redhat.com/show_bug.cgi?id=1484130 + +but doesn't seem to be getting a lot of traction there. + +Basically, with qemu since at least 2.10, you cannot use a disk image on an SMB share that's mounted with protocol version 3 (I think possibly 2 or higher). This is made much more serious because kernel 4.13 upstream made version 3 the *default* for SMB mounts, because version 1 is insecure and should not be used. + +So basically, anyone with a recent qemu and kernel cannot use disk images stored on an SMB share. This is a major inconvenience for me because, well, an SMB share is exactly where I store my VM disk images, usually: I have a big NAS drive where I keep them all, only now I can't because of this bug, and I'm manually swapping them in and out of the very limited space I have on my system drive (SSD). + +The error you get is: + +qemu-system-x86_64: -drive file=/share/data/isos/vms/desktop_test_1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Failed to get "write" lock +Is another process using the image? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1759492 b/results/classifier/accel-gemma3:12b/vmm/1759492 new file mode 100644 index 000000000..f5c0e7348 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1759492 @@ -0,0 +1,15 @@ + +suspend/resume is not supported for vm with tpm device + +I have used libvirt with qemu to create a vm with tpm device, when I suspend the vm and resume it, libvirt will +raise error: +libvirtError: internal error: process exited while connecting to monitor: Enter char_pty_open +I find some materials: +https://wiki.qemu.org/Features/TPM +https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg05355.html +They present qemu haven't supported tpm suspend/resume, Does someone have any advice on how to resolve the problem? + +qemu version: 2.10.2 +vm image version: centos 7.2 + +Thanks \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1760176 b/results/classifier/accel-gemma3:12b/vmm/1760176 new file mode 100644 index 000000000..2655675a9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1760176 @@ -0,0 +1,6 @@ + +optical drive doesn't open in Lubuntu 18.04 on '12 MacPro + +Running an install to HD of Lubuntu 18.04 and after running update/upgrade this morning now the optical drive door doesn't respond to keyboard "eject" key on a Mac keyboard for '12 MacPro . . . . I tried to use "xfburn" to get the door to open, nothing seems to get it to work that I know of. Yesterday there was no issue . . . . Tried to run "apt -f install" and it showed some old kernels to "autoremove" . . . which I did; didn't try to reboot into old kernel to test, perhaps now old kernel is gone? + +F \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1761027 b/results/classifier/accel-gemma3:12b/vmm/1761027 new file mode 100644 index 000000000..ef5a2ccfc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1761027 @@ -0,0 +1,14 @@ + +Unexpected error: "AioContext polling is not implemented on Windows" + +When run it this error happens: +Unexpected error in aio_context_set_poll_params() at /home/stefan/src/qemu/repo.or.cz/qemu/ar7/util/aio-win32.c:413: +C:\Program Files\qemu\qemu-system-x86_64.exe: AioContext polling is not implemented on Windows + +This application has requested the Runtime to terminate it in an unusual way. +Please contact the application's support team for more information. + + + +System: +Windows 10 x64 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1765 b/results/classifier/accel-gemma3:12b/vmm/1765 new file mode 100644 index 000000000..8f885c59a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1765 @@ -0,0 +1,96 @@ + +Linux kernel fails to boot on powernv machines with nvme device on s390x hosts +Description of problem: +When running a powernv guest with nvme device on a s390x host, the guest linux kernel fails to boot with the following panic: + +``` +nvme nvme0: pci function 0002:01:00.0 +nvme 0002:01:00.0: enabling device (0100 -> 0102) +nvme nvme0: 1/0/0 default/read/poll queues +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +BUG: Kernel NULL pointer dereference on read at 0x00000008 +Faulting instruction address: 0xc0000000000c02ec +Oops: Kernel access of bad area, sig: 11 [#1] +LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV +Modules linked in: nvme powernv_flash(+) rtc_opal ibmpowernv mtd nvme_core +CPU: 0 PID: 100 Comm: pb-console Not tainted 5.10.50-openpower1 #2 +NIP: c0000000000c02ec LR: c00000000050d5dc CTR: c00000000024a2d0 +REGS: c00000003ffdfa00 TRAP: 0300 Not tainted (5.10.50-openpower1) +MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24000402 XER: 20000000 +CFAR: c00000000000f3c0 DAR: 0000000000000008 DSISR: 40000000 IRQMASK: 1 +GPR00: c0000000000ba058 c00000003ffdfc90 c00000000180db00 0000000000000008 +GPR04: 000000000000000a 0000000000000000 c000000002740210 c00000000274e218 +GPR08: c00000000183be00 0000000080000000 0000000000000000 c0080000003ba798 +GPR12: c00000000024a2d0 c000000001a30000 0000000000000000 0000000000000100 +GPR16: 0000000000000004 0000000000000020 0000000000000100 c00000000bbe8080 +GPR20: 0000000000000028 c000000001830100 0000000000000001 0000000000000000 +GPR24: c000000001831a00 c000000001410c00 00000000ffff9097 0000000000400040 +GPR28: 000000000000000a 000000000000000a 0000000000000008 0000000000000000 +NIP [c0000000000c02ec] __arch_spin_trylock+0x4/0x24 +LR [c00000000050d5dc] _raw_spin_lock_irqsave+0x2c/0x78 +Call Trace: +[c00000003ffdfc90] [c00000003ffdfcc0] 0xc00000003ffdfcc0 (unreliable) +[c00000003ffdfcd0] [c0000000000ba058] complete+0x24/0x64 +[c00000003ffdfd10] [c00000000024a2f8] blk_end_sync_rq+0x28/0x3c +[c00000003ffdfd30] [c00000000024f44c] __blk_mq_end_request+0x134/0x160 +[c00000003ffdfd70] [c0080000003b481c] nvme_complete_rq+0xcc/0x13c [nvme_core] +[c00000003ffdfda0] [c0080000000a1078] nvme_pci_complete_rq+0x78/0x108 [nvme] +[c00000003ffdfdd0] [c00000000024de38] blk_done_softirq+0xc0/0xd0 +[c00000003ffdfe30] [c00000000050da20] __do_softirq+0x238/0x28c +[c00000003ffdff20] [c0000000000875d4] __irq_exit_rcu+0x80/0xc8 +[c00000003ffdff50] [c000000000087844] irq_exit+0x18/0x30 +[c00000003ffdff70] [c000000000011c4c] __do_irq+0x80/0xa0 +[c00000003ffdff90] [c00000000001d7a4] call_do_irq+0x14/0x24 +[c00000000bff3960] [c000000000011d20] do_IRQ+0xb4/0xbc +[c00000000bff39f0] [c000000000008fac] hardware_interrupt_common_virt+0x1ac/0x1b0 +--- interrupt: 500 at arch_local_irq_restore+0xac/0xe8 + LR = __raw_spin_unlock_irq+0x34/0x40 +[c00000000bff3cf0] [0000000000000000] 0x0 (unreliable) +[c00000000bff3d20] [c0000000000a8344] __raw_spin_unlock_irq+0x34/0x40 +[c00000000bff3d50] [c0000000000a84b0] finish_task_switch+0x160/0x228 +[c00000000bff3df0] [c0000000000aa3d0] schedule_tail+0x20/0x8c +[c00000000bff3e20] [c00000000000cb50] ret_from_fork+0x4/0x54 +Instruction dump: +a14d0b7a 7da96b78 2f8a0000 419e0010 39400000 b14d0b7a 7c0004ac a1490b78 +394affff b1490b78 4e800020 812d0000 <7d401829> 2c0a0000 40c20010 7d20192d +---[ end trace 6b7a11c45e4fc465 ]--- + +Kernel panic - not syncing: Fatal exception +Rebooting in 30 seconds.. +``` + +The issue has been noticed while running the avocado tests on a s390x host: + +``` +make check-venv +./tests/venv/bin/avocado run tests/avocado/boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8 +``` + +But they can also be reproduced manually: +Steps to reproduce: +1. wget https://github.com/open-power/op-build/releases/download/v2.7/zImage.epapr +2. ./qemu-system-ppc64 -nographic -M powernv8 -kernel zImage.epapr -append "console=tty0 console=hvc0" -device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 -device nvme,bus=pcie.2,addr=0x0,serial=1234 diff --git a/results/classifier/accel-gemma3:12b/vmm/1766904 b/results/classifier/accel-gemma3:12b/vmm/1766904 new file mode 100644 index 000000000..7def98bec --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1766904 @@ -0,0 +1,17 @@ + +Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg + +After upgrading from qemu 2.10.0+dfsg-2 to 2.12~rc3+dfsg-2 (on debian sid host), centos 7 guest started to show freezes and ata errors in dmesg during hdd workloads with writing many small files and repeated fsyncs. + +Host kernel 4.15.0-3-amd64. +Guest kernel 3.10.0-693.21.1.el7.x86_64 (slightly older guest kernel was tested too with same result). + +Script that reproduces the bug (first run usualy goes smooth, second and later runs result in dmesg errors and freezes): + +http://paste.debian.net/hidden/472fb220/ + +Sample of error messages in guest dmesg: + +http://paste.debian.net/hidden/8219e234/ + +A workaround that I am using right now: I have detached this SATA storage and reattached the same .qcow2 file as SCSI - this has fixed the issue for me. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1771238 b/results/classifier/accel-gemma3:12b/vmm/1771238 new file mode 100644 index 000000000..3f582294d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1771238 @@ -0,0 +1,157 @@ + +Not able to passthrough > 32 PCIe devices to a KVM Guest + +Using an Ubuntu Server 16.04-based host with KVM hypervisor installed, we are unable to launch a vanilla Ubuntu Server 16.04.4 guest with >= 32 PCIe devices. It is 100% reproducible. Using fewer PCIe devices works fine. We are using the vanilla kvm and qemu packages from the Canonical repos. + +The ultimate goal is to create a KVM Guest wherein I can passthrough 44 PCI devices. + +When a KVM Guest launches, it also has some internal PCIe devices including host bridge, USB, IDE (for virtual disk), and virtual nic etc. + +Script used to launch all devices looks like this: + +#!/bin/bash +NAME=16gpuvm + +sudo qemu-img create -f qcow2 /home/lab/kvm/images/${NAME}.img 40G && +sudo virt-install \ +--name ${NAME} \ +--ram 716800 \ +--vcpus 88 \ +--disk path=/home/lab/kvm/images/${NAME}.img,format=qcow2 \ +--network bridge=virbr0 \ +--graphics none \ +--host-device 34:00.0 \ +--host-device 36:00.0 \ +--host-device 39:00.0 \ +--host-device 3b:00.0 \ +--host-device 57:00.0 \ +--host-device 59:00.0 \ +--host-device 5c:00.0 \ +--host-device 5e:00.0 \ +--host-device 61:00.0 \ +--host-device 62:00.0 \ +--host-device 63:00.0 \ +--host-device 65:00.0 \ +--host-device 66:00.0 \ +--host-device 67:00.0 \ +--host-device 35:00.0 \ +--host-device 3a:00.0 \ +--host-device 58:00.0 \ +--host-device 5d:00.0 \ +--host-device 2e:00.0 \ +--host-device 2f:00.0 \ +--host-device 51:00.0 \ +--host-device 52:00.0 \ +--host-device b7:00.0 \ +--host-device b9:00.0 \ +--host-device bc:00.0 \ +--host-device be:00.0 \ +--host-device e0:00.0 \ +--host-device e2:00.0 \ +--host-device e5:00.0 \ +--host-device e7:00.0 \ +--host-device c1:00.0 \ +--host-device c2:00.0 \ +--host-device c3:00.0 \ +--host-device c5:00.0 \ +--host-device c6:00.0 \ +--host-device c7:00.0 \ +--host-device b8:00.0 \ +--host-device bd:00.0 \ +--host-device e1:00.0 \ +--host-device e6:00.0 \ +--host-device b1:00.0 \ +--host-device b2:00.0 \ +--host-device da:00.0 \ +--host-device db:00.0 \ +--console pty,target_type=serial \ +--location http://ftp.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64 \ +--initrd-inject=/home/lab/kvm/images/preseed.cfg \ +--extra-args=" +console=ttyS0,115200 +locale=en_US +console-keymaps-at/keymap=us +console-setup/ask_detect=false +console-setup/layoutcode=us +keyboard-configuration/layout=USA +keyboard-configuration/variant=USA +hostname=${NAME} +file=file:/preseed.cfg +" + +Passing > 32 device causes this issue: 32nd device hits a DPC error and the host/HV crashes: + + +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.977496] dpc 0000:5b:10.0:pcie210: DPC containment event, status:0x0009 source:0x0000 +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.977500] dpc 0000:5b:10.0:pcie210: DPC unmasked uncorrectable error detected, remove downstream devices +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.994326] vfio-pci 0000:5e:00.0: Refused to change power state, currently in D3 +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.994427] iommu: Removing device 0000:5e:00.0 from group 92 + + +From syslog (attached) + +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194358] dpc 0000:bb:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194387] dpc 0000:bb:10.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194413] dpc 0000:d9:00.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194439] dpc 0000:d9:01.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194472] dpc 0000:d9:02.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194499] dpc 0000:d9:03.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194526] dpc 0000:d9:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194553] dpc 0000:d9:0c.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194583] dpc 0000:df:00.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194619] dpc 0000:df:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194649] dpc 0000:df:10.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194679] dpc 0000:e4:00.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194709] dpc 0000:e4:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194742] dpc 0000:e4:10.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194763] pciehp 0000:00:1c.0:pcie004: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195036] pciehp 0000:60:02.0:pcie204: Slot #2 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195278] pciehp 0000:60:0a.0:pcie204: Slot #10 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195513] pciehp 0000:c0:02.0:pcie204: Slot #2 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195753] pciehp 0000:c0:0a.0:pcie204: Slot #10 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196196] efifb: probing for efifb +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196242] efifb: framebuffer at 0x9c000000, using 1920k, total 1920k +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196247] efifb: mode is 800x600x32, linelength=3200, pages=1 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196250] efifb: scrolling: redraw +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196254] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.206652] Console: switching to colour frame buffer device 100x37 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.217034] fb0: EFI VGA frame buffer device +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.217173] intel_idle: MWAIT substates: 0x2020 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.217174] intel_idle: v0.4.1 model 0x55 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.220874] intel_idle: lapic_timer_reliable_states 0xffffffff +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.221219] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.221590] ACPI: Power Button [PWRF] +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.231089] ERST: Error Record Serialization Table (ERST) support is initialized. +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.231312] pstore: using zlib compression +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.231444] pstore: Registered erst as persistent store backend +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.232503] GHES: APEI firmware first mode is enabled by APEI bit and WHEA _OSC. + + + +All PCI devices go offline include NVMe. + +OS Drives go away, RAID-1 is remounted as RO, and eventually system crashes. + + +Apr 25 22:37:13 xpl-evt-16 rsyslogd-2007: action 'action 9' suspended, next retry is Wed Apr 25 22:37:43 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ] +Apr 25 22:37:13 xpl-evt-16 systemd-udevd[1383]: Process '/sbin/mdadm --incremental /dev/nvme1n1p2 --offroot' failed with exit code 1. +Apr 25 22:37:13 xpl-evt-16 systemd-udevd[1371]: Process '/sbin/mdadm --incremental /dev/nvme0n1p2 --offroot' failed with exit code 1. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting Apply Kernel Variables... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounted Configuration File System. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounted FUSE Control File System. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Started Apply Kernel Variables. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Found device /dev/disk/by-uuid/269E-631A. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting File System Check on /dev/disk/by-uuid/269E-631A... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Started File System Check Daemon to report status. +Apr 25 22:37:13 xpl-evt-16 systemd-fsck[1576]: fsck.fat 3.0.28 (2015-05-16) +Apr 25 22:37:13 xpl-evt-16 systemd-fsck[1576]: /dev/nvme0n1p1: 10 files, 1168/130812 clusters +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Started File System Check on /dev/disk/by-uuid/269E-631A. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounting /boot/efi... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounted /boot/efi. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Reached target Local File Systems. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting Preprocess NFS configuration... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting Create Volatile Files and Directories... +Apr 25 22:37:13 xpl-evt-16 systemd-tmpfiles[1714]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting openibd - configure Mellanox devices... +Apr 25 22:37:13 xpl-evt-16 kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0x42/0x50d with crng_init=0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1771570 b/results/classifier/accel-gemma3:12b/vmm/1771570 new file mode 100644 index 000000000..aa23c90f3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1771570 @@ -0,0 +1,12 @@ + +qemu-aarch64 $program > $file doesn't pipe output to file in 2.12.0 + +Running qemu-aarch64 $program > $file doesn't pipe anything to $file. The file is created but empty. + +qemu-aarch64 --help > $file works, so piping output in my system seems to work. +qemu-x86_64 $program > $file works, too. + +I'm running version 2.12.0 build from source with ./configure && make + +Output of uname -a: +Linux zhostname> 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1775555 b/results/classifier/accel-gemma3:12b/vmm/1775555 new file mode 100644 index 000000000..30e187c3b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1775555 @@ -0,0 +1,371 @@ + +guest migration 100% cpu freeze bug + +# Investigate migration cpu hog(100%) bug + +I have some issues when migrating from qemu 2.6.2 to qemu 2.11.1. +The hypervisors are running kernel 4.9.92 on debian stretch with libvirt v4.0.0. +Linux, libvirt and qemu are all custom compiled. + +I migrated around 21.000 vms from qemu 2.6.2 to qemu 2.11.1 and every once in a while a vm is stuck at 100% cpu after the migration from 2.6.2 to 2.11.1. This happend with about 50-60 vms so far. + +I attached gdb to a vcpu thread of one stuck vm, and a bt showed the following info: +#0 0x00007f4f19949dd7 in ioctl () at ../sysdeps/unix/syscall-template.S:84 +#1 0x0000557c9edede47 in kvm_vcpu_ioctl (cpu=cpu@entry=0x557ca1058840, type=type@entry=0xae80) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050 +#2 0x0000557c9ededfb6 in kvm_cpu_exec (cpu=cpu@entry=0x557ca1058840) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887 +#3 0x0000557c9edcab44 in qemu_kvm_cpu_thread_fn (arg=0x557ca1058840) at /home/dbosschieter/src/qemu-pkg/src/cpus.c:1128 +#4 0x00007f4f19c0f494 in start_thread (arg=0x7f4f053f3700) at pthread_create.c:333 +#5 0x00007f4f19951acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +The ioctl call is a ioctl(18, KVM_RUN and it looks like it is looping inside the vm itself. + +I saved the state of the VM (with `virsh save`) after I found it was hanging on its vcpu threads. Then I restored this vm on a test environment running the same kernel, QEMU and libvirt version). After the restore the VM still was haning at 100% cpu usage on all the vcpus. +I tried to use the perf kvm guest option to trace the guest vm with a copy of the kernel, modules and kallsyms files from inside the guest vm and I got the following trace: + +$ perf kvm --guest --guestkallsyms=kallsyms --guestmodules=modules record -g -p 14471 -o perf.data +$ perf kvm --guest --guestkallsyms=kallsyms --guestmodules=modules report -i perf.data --stdio > analyze + +# To display the perf.data header info, please use --header/--header-only options. +# +# +# Total Lost Samples: 0 +# +# Samples: 105K of event 'cycles' +# Event count (approx.): 67588147605 +# +# Children Self Command Shared Object Symbol Parent symbol +# ........ ........ ....... ....................... .......................................... ............. +# + 28.79% 28.79% :16028 [guest.kernel.kallsyms] [g] fuse_get_root_inode [other] + 23.48% 23.48% :16030 [guest.kernel.kallsyms] [g] ftrace_raw_output_hrtimer_init [other] + 7.32% 7.32% :16029 [guest.kernel.kallsyms] [g] do_sysfs_unregistration [other] + 4.82% 4.82% :16029 [guest.kernel.kallsyms] [g] posix_cpu_clock_get [other] + 4.20% 4.20% :16030 [guest.kernel.kallsyms] [g] ftrace_raw_output_timer_expire_entry [other] + 3.87% 3.87% :16029 [guest.kernel.kallsyms] [g] kvm_init_debugfs [other] + 3.66% 3.66% :16029 [guest.kernel.kallsyms] [g] fat_msg [other] + 3.11% 3.11% :16029 [guest.kernel.kallsyms] [g] match_token [other] + 3.07% 3.07% :16029 [guest.kernel.kallsyms] [g] load_balance [other] + 1.87% 1.87% :16029 [guest.kernel.kallsyms] [g] kvm_pv_guest_cpu_reboot [other] + 1.69% 1.69% :16031 [guest.kernel.kallsyms] [g] kvm_init_debugfs [other] + 1.59% 1.59% :16029 [guest.kernel.kallsyms] [g] sys_kcmp [other] + 1.19% 1.19% :16031 [guest.kernel.kallsyms] [g] save_paranoid [other] + 0.82% 0.82% :16031 [guest.kernel.kallsyms] [g] kvm_pv_guest_cpu_reboot [other] + 0.69% 0.69% :16031 [guest.kernel.kallsyms] [g] kvm_cpu_notify [other] + 0.54% 0.54% :16031 [guest.kernel.kallsyms] [g] rcu_process_callbacks [other] + 0.46% 0.46% :16030 [guest.kernel.kallsyms] [g] ftrace_raw_output_hrtimer_start [other] + 0.43% 0.43% :16031 [guest.kernel.kallsyms] [g] tg_set_cfs_bandwidth [other] + 0.42% 0.42% :16030 [guest.kernel.kallsyms] [g] ftrace_raw_output_hrtimer_expire_entry [other] + 0.37% 0.37% :16029 [guest.kernel.kallsyms] [g] amd_get_mmconfig_range [other] + 0.35% 0.35% :16031 [guest.kernel.kallsyms] [g] sys_kcmp [other] + 0.35% 0.35% :16031 [guest.kernel.kallsyms] [g] console_unlock [other] + 0.34% 0.34% :16029 [guest.kernel.kallsyms] [g] __fat_fs_error [other] + 0.31% 0.31% :16031 [guest.kernel.kallsyms] [g] do_sysfs_unregistration [other] + 0.24% 0.24% :16031 [guest.kernel.kallsyms] [g] paravirt_write_msr [other] + 0.24% 0.24% :16029 [guest.kernel.kallsyms] [g] parse_no_kvmclock [other] + 0.24% 0.24% :16029 [guest.kernel.kallsyms] [g] kvm_save_sched_clock_state [other] + 0.21% 0.21% :16030 [guest.kernel.kallsyms] [g] ptrace_request [other] + 0.20% 0.20% :16031 [guest.kernel.kallsyms] [g] print_stack_trace [other] + 0.20% 0.20% :16031 [guest.kernel.kallsyms] [g] build_sched_domains [other] + 0.20% 0.20% :16031 [guest.kernel.kallsyms] [g] __synchronize_srcu [other] + 0.17% 0.17% :16031 [guest.kernel.kallsyms] [g] do_cpu_nanosleep [other] + 0.16% 0.16% :16031 [guest.kernel.kallsyms] [g] amd_get_mmconfig_range [other] + 0.16% 0.16% :16031 [guest.kernel.kallsyms] [g] irq_node_proc_show [other] + 0.15% 0.15% :16031 [guest.kernel.kallsyms] [g] __srcu_read_lock [other] + 0.15% 0.15% :16031 [guest.kernel.kallsyms] [g] posix_cpu_nsleep_restart [other] + 0.11% 0.11% :16031 [guest.kernel.kallsyms] [g] parse_no_kvmclock [other] + 0.11% 0.11% :16031 [guest.kernel.kallsyms] [g] __irq_domain_add [other] + 0.11% 0.11% :16031 [guest.kernel.kallsyms] [g] print_tickdevice.isra.4 [other] + 0.10% 0.10% :16031 [guest.kernel.kallsyms] [g] kvm_save_sched_clock_state [other] + 0.09% 0.09% :16031 [guest.kernel.kallsyms] [g] sysfs_unbind_tick_dev [other] + 0.09% 0.09% :16029 [guest.kernel.kallsyms] [g] __sched_setscheduler [other] + 0.09% 0.09% :16031 [guest.kernel.kallsyms] [g] process_srcu [other] + 0.08% 0.08% :16031 [guest.kernel.kallsyms] [g] avc_compute_av [other] + 0.08% 0.08% :16031 [guest.kernel.kallsyms] [g] arch_remove_reservations [other] + 0.08% 0.08% :16031 [guest.kernel.kallsyms] [g] __switch_to_xtra [other] + 0.08% 0.08% :16031 [guest.kernel.kallsyms] [g] __create_irqs [other] + 0.08% 0.08% :16031 [guest.kernel.kallsyms] [g] ftrace_raw_output_irq_handler_exit [other] + 0.07% 0.07% :16031 [guest.kernel.kallsyms] [g] posix_clock_read [other] + 0.07% 0.07% :16031 [guest.kernel.kallsyms] [g] posix_clock_poll [other] + 0.07% 0.07% :16031 [guest.kernel.kallsyms] [g] native_cpu_up [other] + 0.06% 0.06% :16031 [guest.kernel.kallsyms] [g] do_nmi [other] + 0.06% 0.06% :16031 [guest.kernel.kallsyms] [g] rcu_try_advance_all_cbs [other] + 0.06% 0.06% :16031 [guest.kernel.kallsyms] [g] fat_msg [other] + 0.05% 0.05% :16031 [guest.kernel.kallsyms] [g] check_tsc_warp [other] + 0.04% 0.04% :16031 [guest.kernel.kallsyms] [g] tick_handle_oneshot_broadcast [other] + 0.03% 0.03% :16031 [guest.kernel.kallsyms] [g] set_cpu_itimer [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] arp_ignore [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] store_powersave_bias_gov_sys [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] cleanup_srcu_struct [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] create_prof_cpu_mask [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] alarm_timer_nsleep [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] time_cpufreq_notifier [other] + 0.02% 0.02% :16030 [guest.kernel.kallsyms] [g] ftrace_raw_output_itimer_state [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] tick_check_new_device [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] init_timer_key [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] tick_setup_device [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] clockevents_register_device [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] __srcu_read_unlock [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] hpet_rtc_interrupt [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] init_srcu_struct [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] irq_spurious_proc_show [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] rcu_jiffies_till_stall_check [other] + 0.02% 0.02% :16031 [guest.kernel.kallsyms] [g] ksoftirqd_should_run [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] ftrace_raw_output_irq_handler_entry [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] avc_denied.isra.0 [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] __fat_fs_error [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] wakeme_after_rcu [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] prof_cpu_mask_proc_write [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] srcu_barrier [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] tick_get_device [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] irq_domain_add_simple [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] synchronize_srcu_expedited [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] sysfs_show_current_tick_dev [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] tick_is_oneshot_available [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] tick_check_replacement [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] clockevents_notify [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] show_stack [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] debug_kfree [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] tick_do_broadcast.constprop.6 [other] + 0.01% 0.01% :16031 [guest.kernel.kallsyms] [g] sock_rps_save_rxhash.isra.28.part.29 [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] store_ignore_nice_load.isra.3 [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] perf_trace_itimer_expire [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] hrtick_start [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] parse_probe_arg [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] wakeup_softirqd [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] tick_install_replacement [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] detach_if_pending [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] default_affinity_show [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] tick_do_periodic_broadcast [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] ftrace_raw_output_softirq [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] tasklet_kill [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] update_rq_clock [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] tasklet_init [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] arch_local_irq_enable [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] irq_affinity_proc_show [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] store_sampling_down_factor.isra.4 [other] + 0.00% 0.00% :16031 [guest.kernel.kallsyms] [g] amd_get_subcaches [other] + +Also tried a `virsh restore` with the `--bypass-cache` option and ran a perf trace. Noticable is the different trace. See output below: + +# perf trace without filesystem cache: +# To display the perf.data header info, please use --header/--header-only options. +# +# +# Total Lost Samples: 0 +# +# Samples: 1M of event 'cycles' +# Event count (approx.): 798928823821 +# +# Children Self Command Shared Object Symbol +# ........ ........ ....... ....................... .......................................... +# + 25.32% 25.32% :34335 [guest.kernel.kallsyms] [g] ftrace_raw_output_hrtimer_init + 9.55% 9.55% :34334 [guest.kernel.kallsyms] [g] do_sysfs_unregistration + 5.83% 5.83% :34335 [guest.kernel.kallsyms] [g] ftrace_raw_output_timer_expire_entry + 5.60% 5.60% :34334 [guest.kernel.kallsyms] [g] posix_cpu_clock_get + 4.37% 4.37% :34334 [guest.kernel.kallsyms] [g] kvm_init_debugfs + 4.30% 4.30% :34334 [guest.kernel.kallsyms] [g] fat_msg + 3.63% 3.63% :34334 [guest.kernel.kallsyms] [g] match_token + 3.44% 3.44% :34334 [guest.kernel.kallsyms] [g] load_balance + 3.28% 3.28% :34333 [guest.kernel.kallsyms] [g] save_paranoid + 2.25% 2.25% :34334 [guest.kernel.kallsyms] [g] kvm_pv_guest_cpu_reboot + 2.19% 2.19% :34335 [guest.kernel.kallsyms] [g] ftrace_raw_output_hrtimer_expire_entry + 1.89% 1.89% :34334 [guest.kernel.kallsyms] [g] sys_kcmp + 1.73% 1.73% :34336 [guest.kernel.kallsyms] [g] kvm_init_debugfs + 1.58% 1.58% :34335 [guest.kernel.kallsyms] [g] ftrace_raw_output_hrtimer_start + 1.26% 1.26% :34336 [guest.kernel.kallsyms] [g] save_paranoid + 1.09% 1.09% :34333 [guest.kernel.kallsyms] [g] kvm_init_debugfs + 1.01% 1.01% :34333 [unknown] [u] 0x0000000000434c1b + 0.94% 0.94% :34336 [guest.kernel.kallsyms] [g] tg_set_cfs_bandwidth + 0.88% 0.88% :34333 [guest.kernel.kallsyms] [g] avc_denied.isra.0 + 0.87% 0.87% :34336 [guest.kernel.kallsyms] [g] kvm_pv_guest_cpu_reboot + 0.73% 0.73% :34333 [guest.kernel.kallsyms] [g] kvm_pv_guest_cpu_reboot + 0.68% 0.68% :34336 [guest.kernel.kallsyms] [g] kvm_cpu_notify + 0.65% 0.65% :34336 [guest.kernel.kallsyms] [g] rcu_process_callbacks + 0.57% 0.57% :34333 [guest.kernel.kallsyms] [g] paravirt_write_msr + 0.56% 0.56% :34333 [guest.kernel.kallsyms] [g] avc_compute_av + 0.40% 0.40% :34334 [guest.kernel.kallsyms] [g] __fat_fs_error + 0.39% 0.39% :34334 [guest.kernel.kallsyms] [g] amd_get_mmconfig_range + 0.39% 0.39% :34335 [guest.kernel.kallsyms] [g] ptrace_request + 0.38% 0.38% :34336 [guest.kernel.kallsyms] [g] sys_kcmp + 0.34% 0.34% :34333 [guest.kernel.kallsyms] [g] posix_cpu_nsleep_restart + 0.32% 0.32% :34336 [guest.kernel.kallsyms] [g] do_sysfs_unregistration + 0.31% 0.31% :34336 [guest.kernel.kallsyms] [g] console_unlock + 0.30% 0.30% :34334 [guest.kernel.kallsyms] [g] kvm_save_sched_clock_state + 0.29% 0.29% :34334 [guest.kernel.kallsyms] [g] parse_no_kvmclock + 0.27% 0.27% :34333 [guest.kernel.kallsyms] [g] do_sysfs_unregistration + 0.27% 0.27% :34333 [guest.kernel.kallsyms] [g] check_tsc_warp + 0.26% 0.26% :34333 [guest.kernel.kallsyms] [g] ksoftirqd_should_run + 0.26% 0.26% :34336 [guest.kernel.kallsyms] [g] paravirt_write_msr + 0.26% 0.26% :34333 [guest.kernel.kallsyms] [g] amd_get_mmconfig_range + 0.25% 0.25% :34333 [guest.kernel.kallsyms] [g] sys_kcmp + 0.22% 0.22% :34336 [guest.kernel.kallsyms] [g] build_sched_domains + 0.22% 0.22% :34333 [guest.kernel.kallsyms] [g] do_cpu_nanosleep + 0.22% 0.22% :34333 [guest.kernel.kallsyms] [g] print_stack_trace + 0.21% 0.21% :34336 [guest.kernel.kallsyms] [g] irq_node_proc_show + 0.19% 0.19% :34336 [guest.kernel.kallsyms] [g] print_stack_trace + 0.19% 0.19% :34336 [guest.kernel.kallsyms] [g] __srcu_read_lock + 0.18% 0.18% :34336 [guest.kernel.kallsyms] [g] __synchronize_srcu + 0.17% 0.17% :34333 [guest.kernel.kallsyms] [g] __create_irqs + 0.17% 0.17% :34336 [guest.kernel.kallsyms] [g] do_cpu_nanosleep + 0.17% 0.17% :34336 [guest.kernel.kallsyms] [g] amd_get_mmconfig_range + 0.15% 0.15% :34336 [guest.kernel.kallsyms] [g] posix_cpu_nsleep_restart + 0.14% 0.14% :34333 [guest.kernel.kallsyms] [g] rcu_process_callbacks + 0.14% 0.14% :34333 [guest.kernel.kallsyms] [g] rcu_try_advance_all_cbs + 0.13% 0.13% :34336 [guest.kernel.kallsyms] [g] parse_no_kvmclock + 0.11% 0.11% :34333 [guest.kernel.kallsyms] [g] tasklet_init + 0.11% 0.11% :34336 [guest.kernel.kallsyms] [g] process_srcu + 0.11% 0.11% :34336 [guest.kernel.kallsyms] [g] kvm_save_sched_clock_state + 0.11% 0.11% :34333 [guest.kernel.kallsyms] [g] sysfs_unbind_tick_dev + 0.10% 0.10% :34336 [guest.kernel.kallsyms] [g] __switch_to_xtra + 0.10% 0.10% :34334 [guest.kernel.kallsyms] [g] __sched_setscheduler + 0.10% 0.10% :34333 [guest.kernel.kallsyms] [g] print_tickdevice.isra.4 + 0.10% 0.10% :34336 [guest.kernel.kallsyms] [g] sysfs_unbind_tick_dev + 0.10% 0.10% :34336 [guest.kernel.kallsyms] [g] print_tickdevice.isra.4 + 0.10% 0.10% :34336 [guest.kernel.kallsyms] [g] posix_clock_read + 0.09% 0.09% :34333 [guest.kernel.kallsyms] [g] parse_no_kvmclock + 0.09% 0.09% :34333 [guest.kernel.kallsyms] [g] posix_clock_poll + 0.09% 0.09% :34336 [guest.kernel.kallsyms] [g] __irq_domain_add + 0.09% 0.09% :34336 [guest.kernel.kallsyms] [g] avc_compute_av + 0.09% 0.09% :34333 [guest.kernel.kallsyms] [g] posix_clock_read + 0.09% 0.09% :34333 [guest.kernel.kallsyms] [g] hpet_rtc_interrupt + 0.09% 0.09% :34336 [guest.kernel.kallsyms] [g] __create_irqs + 0.08% 0.08% :34336 [guest.kernel.kallsyms] [g] posix_clock_poll + 0.08% 0.08% :34336 [guest.kernel.kallsyms] [g] rcu_try_advance_all_cbs + 0.07% 0.07% :34336 [guest.kernel.kallsyms] [g] ftrace_raw_output_irq_handler_exit + 0.07% 0.07% :34336 [guest.kernel.kallsyms] [g] arch_remove_reservations + 0.07% 0.07% :34333 [guest.kernel.kallsyms] [g] native_cpu_up + 0.07% 0.07% :34336 [guest.kernel.kallsyms] [g] native_cpu_up + 0.07% 0.07% :34336 [guest.kernel.kallsyms] [g] check_tsc_warp + 0.07% 0.07% :34333 [guest.kernel.kallsyms] [g] kvm_save_sched_clock_state + 0.07% 0.07% :34333 [guest.kernel.kallsyms] [g] do_nmi + 0.06% 0.06% :34336 [guest.kernel.kallsyms] [g] do_nmi + 0.06% 0.06% :34335 [guest.kernel.kallsyms] [g] ftrace_raw_output_itimer_state + 0.05% 0.05% :34336 [guest.kernel.kallsyms] [g] fat_msg + 0.04% 0.04% :34336 [guest.kernel.kallsyms] [g] store_powersave_bias_gov_sys + 0.04% 0.04% :34336 [guest.kernel.kallsyms] [g] tick_handle_oneshot_broadcast + 0.04% 0.04% :34336 [guest.kernel.kallsyms] [g] set_cpu_itimer + 0.04% 0.04% :34336 [guest.kernel.kallsyms] [g] cleanup_srcu_struct + 0.03% 0.03% :34336 [guest.kernel.kallsyms] [g] __srcu_read_unlock + 0.03% 0.03% :34336 [guest.kernel.kallsyms] [g] time_cpufreq_notifier + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] irq_spurious_proc_show + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] alarm_timer_nsleep + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] ksoftirqd_should_run + 0.02% 0.02% :34333 [guest.kernel.kallsyms] [g] tg_set_cfs_bandwidth + 0.02% 0.02% :34333 [guest.kernel.kallsyms] [g] create_prof_cpu_mask + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] create_prof_cpu_mask + 0.02% 0.02% :34333 [guest.kernel.kallsyms] [g] fat_msg + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] tick_check_new_device + 0.02% 0.02% :34333 [guest.kernel.kallsyms] [g] __switch_to_xtra + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] tick_setup_device + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] init_timer_key + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] rcu_jiffies_till_stall_check + 0.02% 0.02% :34333 [guest.kernel.kallsyms] [g] ftrace_raw_output_irq_handler_exit + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] arp_ignore + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] clockevents_register_device + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] hpet_rtc_interrupt + 0.02% 0.02% :34336 [guest.kernel.kallsyms] [g] init_srcu_struct + 0.01% 0.01% :34333 [guest.kernel.kallsyms] [g] irq_node_proc_show + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] __fat_fs_error + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] tick_check_replacement + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] avc_denied.isra.0 + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] tick_get_device + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] irq_affinity_proc_show + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] sysfs_show_current_tick_dev + 0.01% 0.01% :34333 [guest.kernel.kallsyms] [g] __fat_fs_error + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] ftrace_raw_output_irq_handler_entry + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] tick_is_oneshot_available + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] irq_domain_add_simple + 0.01% 0.01% :34333 [guest.kernel.kallsyms] [g] irq_spurious_proc_show + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] tick_do_broadcast.constprop.6 + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] sock_rps_save_rxhash.isra.28.part.29 + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] prof_cpu_mask_proc_write + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] perf_trace_itimer_expire + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] srcu_barrier + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] store_ignore_nice_load.isra.3 + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] wakeme_after_rcu + 0.01% 0.01% :34333 [guest.kernel.kallsyms] [g] ftrace_raw_output_irq_handler_entry + 0.01% 0.01% :34333 [guest.kernel.kallsyms] [g] ftrace_raw_output_softirq + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] debug_kfree + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] clockevents_notify + 0.01% 0.01% :34336 [guest.kernel.kallsyms] [g] parse_probe_arg + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] hrtick_start + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] detach_if_pending + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] tasklet_init + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] show_stack + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] wakeup_softirqd + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] arch_local_irq_enable + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] tasklet_kill + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] default_affinity_show + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] ftrace_raw_output_softirq + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] store_sampling_down_factor.isra.4 + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] synchronize_srcu_expedited + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] update_rq_clock + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] tick_do_periodic_broadcast + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] tick_install_replacement + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] amd_get_subcaches + 0.00% 0.00% :34334 [guest.kernel.kallsyms] [g] amd_get_subcaches + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] tick_handle_periodic + 0.00% 0.00% :34336 [guest.kernel.kallsyms] [g] __page_cache_alloc + +I am not sure how correct the symbol mapping of perf is, so I don't know if this is usable at all. + +I have dumped info registers with the `qemu-monitor-command` command after the migration problematic VM and this gave the following output: + +RAX=0000000000001975 RBX=ffff8802342fc000 RCX=000000000000beac RDX=000000000000beaa +RSI=000000000000beac RDI=ffff8802342fc000 RBP=ffff880233d3fb18 RSP=ffff880233d3fb18 +R8 =0000000000000286 R9 =ffff8800a71eee40 R10=ffff8800a71eeed4 R11=000000000000000a +R12=ffff8802342fc000 R13=ffffffff81cdf010 R14=ffff880233d3fb58 R15=ffff88003672b200 +RIP=ffffffff817360b7 RFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 000fffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 000fffff 00000000 +FS =0000 0000000000000000 000fffff 00000000 +GS =0000 ffff88023fc00000 000fffff 00000000 +LDT=0000 0000000000000000 000fffff 00000000 +TR =0040 ffff88023fc04440 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88023fc0c000 0000007f +IDT= ffffffffff576000 00000fff +CR0=8005003b CR2=0000000000408950 CR3=0000000232098000 CR4=00000670 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001fa0 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=ffffffffff0000ff0000000000000000 XMM01=0000010101000000ffffffffffffffff +XMM02=00007fe302de17006776615f64616f6c XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000ff0000 +XMM06=5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b XMM07=20202020202020202020202020202020 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00ff000000ff0000000000000000ff00 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 + +And I looped this for a minute to check were the RIP is changing to: +136 RIP=0000000000434c1b +173 RIP=ffffffff8105144a + 2 RIP=ffffffff810521ff + 1 RIP=ffffffff81070816 + + +I tried to reproduce this with some manual actions prior to migrating between qemu 2.6.2 and 2.11.1 on our testing environment using similar hardware (56 core model name: Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz) +And I was not able to reproduce this, i tried the following: +- restore without filesystem caches (see new perf traces below) +- create vm with same kernel as stuck vm +- restore paused detach net device and virtio block device (detach doesn't work) +- try to do a lot of network and disk io while migrating +- ecrypt fs actions during migration +- migrate 4000 times between 2.6.2 -> 2.11 using loop +- add extra timer calls inside guest for migrate loop (done using cyclictest) +- try with guest kernel 3.13.0-145-generic, same kernel vm was running with this issue +- try host clock/timer calls on 2.11.1 host prior and during migration bound on first cpu core (cyclictest -a 0 -c 1 -d 200 -H -l 1 -t 2) + +I asked the vm owner what he is doing on his vm, and he told me that he is using 80% of his mem around 14G of the 16G, the vm is running a tomcat 7 server and a libreoffice deamon the vm has a load of 1.0 and runs Ubuntu 14.04 with kernel 3.13.0-145. + +The other vms were running centos 6, centos 7, debian 7, debian 8, ubuntu 13.10, ubuntu 14.04, ubuntu 12.04 the majority of these vms are running linux kernel 3.*. + +The thing is I am actually out of ideas for reproducing this, and I am not sure how to pinpoint this issue, I would like some help and possible some extra tips on debugging. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1776760 b/results/classifier/accel-gemma3:12b/vmm/1776760 new file mode 100644 index 000000000..d808e4b2d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1776760 @@ -0,0 +1,55 @@ + +Loading from a saved state results in blue screen due to qxl_dod driver + +Versions: +Arch Linux (kernel 4.16.13) +Qemu 2.12 +libvirt 4.3.0 +Windows 10 1803 latest updates installed under libvirt management +Spice tools 0.132 +QXL DOD driver 0.18 (from redhat server) + +Steps to reproduce: +1. Boot Windows (xml is attached) +2. Save VM state through libvirt interface +3. Restore VM state through libvirt interface + +Result: +Blue screen. Previously, the result was high CPU usage and a black screen, nonresponsive VM; I could only force shut down or force reset it. + +The blue screen mentioned the qxl DOD driver as the culprit, the created minidump shows "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED" as error. I can provide the memory.dmp file if it's at all helpful (it's around 250 MB in size). + +libvirt domain logs for the above actions: +2018-06-13 18:59:49.913+0000: starting up libvirt version: 4.3.0, qemu version: 2.12.0, hostname: arch-vaio.localdomain +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name guest=Windows,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-Windows/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Nehalem,vme=on,ss=on,pcid=on,x2apic=on,tsc-deadline=on,hypervisor=on,arat=on,tsc_adjust=on,rdtscp=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid f14684d3-5f81-4743-8512-e516d85ca2c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-Windows/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/mnt/media/Qemu/windows10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:08:31,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input2,bus=usb.0,port=3 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2018-06-13T18:59:50.018852Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/6 (label charserial0) +main_channel_link: add main channel client +inputs_connect: inputs channel client create +red_qxl_set_cursor_peer: +main_channel_handle_message: agent start +main_channel_handle_message: agent start +main_channel_handle_message: agent start +main_channel_handle_message: agent start +main_channel_handle_message: agent start +main_channel_handle_message: agent start +main_channel_handle_message: agent start +2018-06-13 20:28:19.077+0000: shutting down, reason=saved +2018-06-13T20:28:19.118226Z qemu-system-x86_64: terminating on signal 15 from pid 457 (/usr/bin/libvirtd) +red_channel_client_disconnect: rcc=0x7f7eaa3d8a30 (channel=0x7f7eaa34d300 type=5 id=0) +red_channel_client_disconnect: rcc=0x7f7e22bf04b0 (channel=0x7f7eaa34d3c0 type=6 id=0) +red_channel_client_disconnect: rcc=0x7f7e22bd89b0 (channel=0x7f7e214599a0 type=9 id=0) +red_channel_client_disconnect: rcc=0x7f7eaa3de270 (channel=0x7f7e21459a70 type=9 id=1) +2018-06-13 20:29:04.933+0000: starting up libvirt version: 4.3.0, qemu version: 2.12.0, hostname: arch-vaio.localdomain +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name guest=Windows,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-Windows/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Nehalem,vme=on,ss=on,pcid=on,x2apic=on,tsc-deadline=on,hypervisor=on,arat=on,tsc_adjust=on,rdtscp=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid f14684d3-5f81-4743-8512-e516d85ca2c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-Windows/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/mnt/media/Qemu/windows10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:08:31,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input1,bus=usb.0,port=3 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2018-06-13T20:29:05.185563Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/6 (label charserial0) +red_qxl_loadvm_commands: +2018-06-13T20:29:28.899527Z qemu-system-x86_64: warning: usb-redir connection broken during migration + +2018-06-13T20:29:28.904336Z qemu-system-x86_64: warning: usb-redir connection broken during migration + +main_channel_link: add main channel client +main_channel_handle_message: agent start +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create +main_channel_handle_message: agent start +main_channel_handle_message: agent start \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1777 b/results/classifier/accel-gemma3:12b/vmm/1777 new file mode 100644 index 000000000..43d0c748a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1777 @@ -0,0 +1,2 @@ + +Allow logging of IP addresses of connections made to QEMU socket backends for e.g. VNC or SPICE console diff --git a/results/classifier/accel-gemma3:12b/vmm/1777232 b/results/classifier/accel-gemma3:12b/vmm/1777232 new file mode 100644 index 000000000..186fbd8f3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1777232 @@ -0,0 +1,11 @@ + +NVME fails on big writes + +NVME Compliance test 8:3.3.0 tries to write and read back big chunks of pages. Currently, on the latest QEMU operation of size 1024 blocks will fail when device is backed by a file. + +NVME specification has several types of data transfers from guests, one of the is the PRP list (Physical Region Page List). PRP is a list of entries pointing to pages to be written. The list it self resides in a single or multiple pages. + +NVME device maps the PRP list into QEMUSGList which will be me mapped into linux IO vectors. Finally, when the file driver will write the changes, it uses the posix pwritev, which fails if the number of vectors exceeds the maximum. + + +NVME Compliance - https://github.com/nvmecompliance/tnvme/wiki \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1777786 b/results/classifier/accel-gemma3:12b/vmm/1777786 new file mode 100644 index 000000000..873bfd578 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1777786 @@ -0,0 +1,47 @@ + +virtio-gpu-3d.c: change virtio_gpu_fence_poll timer scale + +We use virtio-gpu to accelerate Unigine Heaven Benchmark in VM. But we get only 5 FPS when we use AMD RX460 in our host. +We found that guest os spent a lot of time in waiting for the return of glMapBufferRange/glUnmapBuffer commad. We suspected the host GPU was waiting for fence. So we finally change the timer of fence_poll. Afer change timer from + ms to us， Benchmark result raise up to 22 FPS. + +From a4003af5c4fe92d55353f42767d0c45de95bb78f Mon Sep 17 00:00:00 2001 +From: chen wei <email address hidden> +Date: Fri, 8 Jun 2018 17:34:45 +0800 +Subject: [PATCH] virtio-gpu:improve 3d performance greatly + + opengl function need fence support.when CPU execute opengl function, it need wait fence for synchronize GPU. +so qemu must deal with fence timely as possible. but now the expire time of the timer to deal with fence is 10 ms. +I think it is too long for opengl. So i will change it to 20 ns. + Before change, when i play Unigine_Heaven 3d game with virglrenderer, the fps is 3. atfer change the fps up to 23. + +Signed-off-by: chen wei <email address hidden> +Signed-off-by: wang qiang <email address hidden> +--- + hw/display/virtio-gpu-3d.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c +index 3558f38..c0a5d21 100644 +--- a/hw/display/virtio-gpu-3d.c ++++ b/hw/display/virtio-gpu-3d.c +@@ -582,7 +582,7 @@ static void virtio_gpu_fence_poll(void *opaque) + virgl_renderer_poll(); + virtio_gpu_process_cmdq(g); + if (!QTAILQ_EMPTY(&g->cmdq) || !QTAILQ_EMPTY(&g->fenceq)) { +- timer_mod(g->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10); ++ timer_mod(g->fence_poll, qemu_clock_get_us(QEMU_CLOCK_VIRTUAL) + 20); + } + } + +@@ -629,7 +629,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) + return ret; + } + +- g->fence_poll = timer_new_ms(QEMU_CLOCK_VIRTUAL, ++ g->fence_poll = timer_new_us(QEMU_CLOCK_VIRTUAL, + virtio_gpu_fence_poll, g); + + if (virtio_gpu_stats_enabled(g->conf)) { +-- +2.7.4 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1781280 b/results/classifier/accel-gemma3:12b/vmm/1781280 new file mode 100644 index 000000000..466ec5ee5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1781280 @@ -0,0 +1,10 @@ + +QEMU ignores all but the first control message sent over a Unix socket + +I've written a test program that sends both an SCM_CREDENTIALS and an SCM_RIGHTS cmsg in the same sendmsg call. On native x86-64, armv6 and armv7 Linux, this works as expected (the recvmsg receives both control messages). On QEMU (both qemu-x86_64 and qemu-arm), only the first message is received. + +I've traced the problem back to a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13500 + +This means that writing control messages into an uninitialized buffer makes CMSG_NXTHDR erroneously return NULL even though there's still space inside the allocated buffer. QEMU's logic inside `target_to_host_cmsg` is a bit questionable here, since it stops encoding cmsgs as soon as *either* the host or the target buffer reaches its end, so we lose the target's cmsgs when the host's buffer runs out. However, the host buffer should *never* reach its end before the target buffer does, so an assertion might be more useful there. Anyway, the actual fix for this bug is simply zeroing out the buffer created for the host. I've attached a patch doing that and verified that it fixes the issue. + +The test program I used can be found here: https://gist.github.com/jonas-schievink/cb6e6584a055539d2113f22d91068e2d \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1783422 b/results/classifier/accel-gemma3:12b/vmm/1783422 new file mode 100644 index 000000000..8d2d75d54 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1783422 @@ -0,0 +1,30 @@ + +qemu_clock_get_ns does not take into account icount_time_shift + +Hello, + +If you check the qemu/util/qemu-timer.c you will find the following function: + +597: int64_t qemu_clock_get_ns(QEMUClockType type) +598: { +.... +602: switch (type) { +.... +606: case QEMU_CLOCK_VIRTUAL: +607: if (use_icount) { +608: return cpu_get_icount(); + + +Now on line 606, in case we requested QEMU_CLOCK_VIRTUAL, and we are using icount, the value of cpu_get_icount(); will be returned. + +However if I understand correctly, in order to convert icount to ns, you must use take into account the icount shift -- as defined in the documentation: "The virtual cpu will execute one instruction every 2^N ns of virtual time.". + +Therefor, the correct value to return would be cpu_icount_to_ns(cpu_get_icount()), where cpu_icount_to_ns is defined in cpus.c: + +296: int64_t cpu_icount_to_ns(int64_t icount) +297: { +298: return icount << icount_time_shift; +299: } + +Best Regards, +Humberto "SilverOne" Carvalho \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1784 b/results/classifier/accel-gemma3:12b/vmm/1784 new file mode 100644 index 000000000..e78616327 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1784 @@ -0,0 +1,14 @@ + +Mac M1 Max / Debian guest / Luks password / Switching to graphical login manager (lightdm/Gdm) hangs in 75% +Description of problem: +In approximately 70% of cases I start QEMU with a Debian guest where the Debian guest was installed with full disk encryption, QEMU 'hangs' (does not respond') after I unlock the encrypted guest and the guest tries to start the graphical login manager (gdm or lightdm). + +I need to force quit QEMU, restart it multiple times until the start of the graphical login manager works. +Steps to reproduce: +1. Install Debian with (guided) full disk encryption and either the Gnome or the XFCE desktop environment +2. To be able to unlock the hard disk after the installation finished, the Linux boot parameter 'console=tty1' needs to be added within grub to the Linux command line +3. Try to restart/reboot QEMU several times and QEMU will become unresponsive multiple times in this process. +Additional information: +I encounter this problem for several months now, with different versions of QEMU, macOS and Debian. + +There is one observation, which might help: I installed [DropBear](https://packages.debian.org/buster/dropbear-initramfs) to experiment with remote unlocking of Luks encrypted Linux boxes. It seems, that QEMU does not go into the unresponsive state, when I unlock the hard disk via SSH and not focus the QEMU window until after the graphical login manager started. (Only tried remote unlocking a few times so it is too early to confirm if this works 100% of the time. diff --git a/results/classifier/accel-gemma3:12b/vmm/1785902 b/results/classifier/accel-gemma3:12b/vmm/1785902 new file mode 100644 index 000000000..b38756fff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1785902 @@ -0,0 +1,8 @@ + +local/9pfs: Too many levels of symbolic links + +Version: 2.9.1 + +The primary symptom is resolving symlink fails w/ error "too many levels of symbolic links". + +My analysis showed that local_readlink() uses local_open_nofollow() to open the file and then tries to read it. local_open_nofollow() then tries to open the file w/ O_NOFOLLOW, which obviously fails if the requested file is a symlink. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1787070 b/results/classifier/accel-gemma3:12b/vmm/1787070 new file mode 100644 index 000000000..d5a4a06cc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1787070 @@ -0,0 +1,35 @@ + +Guests using the qxl-vga are freezing + +I have noticed that guests using qxl-vga are freezing. They may freeze after a few minutes or after many hours. The freeze consists of the entire system hanging, except the cursor, but the cursor animation stops too. Changing to tty is not possible after this. There are three things noticed in common on the guests when they freeze: + +-The guest is using the QXL VGA (freezes weren't observed with other VGAs); +-A new workload is starting; +-The mouse cursor is the animated as the one of loading. For example, https://i.imgur.com/raQFteG.png + +The host is Xubuntu 18.04 amd64, QEMU version is 3.0.0-dirty. The guests tested were: + +-openSUSE Tumbleweed; +-openSUSE Leap 15; +-Xubuntu 18.04 Bionic Beaver; +-CentOS 7. + +With openSUSE guests, the install process couldn't even be finished, as the installer would freeze. There were 2 GB of available memory (checked in a tty before the freeze) and netconsole was enabled. Unfortunately, it was impossible to obtain any information from them. This is an image of one openSUSE guest frozen: https://i.imgur.com/ZP0eQKq.png + +The command line used was: + +qemu-system-x86_64 -nodefaults -m 3072 -M pc,usb=true -accel kvm -cpu host -smp cores=2,threads=2 -device qemu-xhci -drive id=centusb,if=none,file=leap.qcow2 -device usb-storage,id=centusb,drive=centusb -netdev user,id=n0 -device usb-tablet,id=usbtablet -device e1000,netdev=n0 -device usb-audio,id=usbaudio -device qxl-vga,xres=1366,yres=768 -display gtk -monitor vc -serial vc -cdrom "openSUSE-Leap-15.0-DVD-x86_64.iso" -boot d + +With CentOS guests, the install process fail sometimes, but sometimes it's able to install. However, on the yum update, it would freeze too. In one instance it froze while updating glibc, which made the guest unbootable. https://i.imgur.com/B3WhSDX.png + +The command line used was: + +qemu-system-x86_64 -nodefaults -m 2048 -M pc,usb=true -accel kvm -cpu host -smp cores=2,threads=2 -device qemu-xhci -drive id=centusb,if=none,file=centos.qcow2 -device usb-storage,id=centusb,drive=centusb -netdev user,id=n0 -device usb-tablet,id=usbtablet -device e1000,netdev=n0 -device usb-audio,id=usbaudio -device virtio-vga,virgl=true -display gtk -monitor vc -serial vc -cdrom "CentOS-7-livecd-GNOME-x86_64.iso" -bios /usr/share/ovmf/OVMF.fd + +With Xubuntu 18.04 guests, the system worked for many hours until the freeze happened. On this case it happened when opening Audacious. Fortunately, the logging services worked for some time, which allowed me to get a relevant message which can be seen at http://termbin.com/nuof . It repeated a few times, but then the logging stopped. https://i.imgur.com/2zckqj5.png shows the guest screen in the moment it froze. + +The command line used was: + +qemu-system-x86_64 -nodefaults -m 1024 -M pc,usb=true -accel kvm -cpu host -smp cores=2,threads=2 -device qemu-xhci -drive id=centusb,if=none,file=xubmini -device usb-storage,id=centusb,drive=centusb -netdev user,id=n0 -device usb-tablet,id=usbtablet -device e1000,netdev=n0 -device usb-audio,id=usbaudio -device qxl-vga,xres=1366,yres=768 -display gtk -monitor vc -serial vc + +I'm sorry for not having more detailed information but, even setting netconsole, openSUSE and CentOS guests were unable to print any information. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1788665 b/results/classifier/accel-gemma3:12b/vmm/1788665 new file mode 100644 index 000000000..62890e335 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1788665 @@ -0,0 +1,43 @@ + +Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection + +Windows 10 (1803) VM using VGA passthrough via qemu script. + +After upgrading Windows 10 Pro VM to version 1803, or possibly after applying the March/April security updates from Microsoft, the VM would show low 2D graphics performance (sluggishness in 2D applications and low Passmark results). + +Turning off Spectre vulnerability protection in Windows remedies the issue. + +Expected behavior: +qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms + +Background: + +Starting in March or April Microsoft began to push driver updates in their updates / security updates. See https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown + +One update concerns the Intel microcode - see https://support.microsoft.com/en-us/help/4100347. It is activated by default within Windows. + +Once the updates are applied within the Windows guest, 2D graphics performance drops significantly. Other performance benchmarks are not affected. + +A bare metal Windows installation does not display a performance loss after the update. See https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/ + +Similar reports can be found here: +https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/ + +Hardware: + +6 core Intel Core i7-3930K (-MT-MCP-) + +Host OS: +Linux Mint 19/Ubuntu 18.04 +Kernel: 4.15.0-32-generic x86_64 +Qemu: QEMU emulator version 2.11.1 +Intel microcode (host): 0x714 +dmesg | grep microcode +[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +[ 2.813340] microcode: Microcode Update Driver: v2.2. + +Note: I manually updated the Intel microcode on the host from 0x713 to 0x714. However, both microcode versions produce the same result in the Windows guest. + +Guest OS: +Windows 10 Pro 64 bit, release 1803 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/179 b/results/classifier/accel-gemma3:12b/vmm/179 new file mode 100644 index 000000000..27a36a640 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/179 @@ -0,0 +1,2 @@ + +qemu guest crashes on spice client USB redirected device removal diff --git a/results/classifier/accel-gemma3:12b/vmm/1790268 b/results/classifier/accel-gemma3:12b/vmm/1790268 new file mode 100644 index 000000000..afe3f8ec1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1790268 @@ -0,0 +1,20 @@ + +the vhd generated by qemu-img not align with MB again. + +I'm using this version on xenial, +andy@bastion:~/temp$ qemu-img -h +qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c) 2004-2008 Fabrice Bellard + +steps to repro: + +dd if=/dev/zero of=/tmp/azure_config_disk_image20180901-22672-16zxelu bs=1048576 count=24 +mkfs.ext4 -F /tmp/azure_config_disk_image20180901-22672-16zxelu -L azure_cfg_dsk +sudo -n mount -o loop /tmp/azure_config_disk_image20180901-22672-16zxelu /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +sudo -n chown andy /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +mkdir -p /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat/configs +sudo -n umount /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +qemu-img convert -f raw -O vpc -o subformat=fixed,force_size /tmp/azure_config_disk_image20180901-22672-16zxelu papapa2.vhd + +unfortunately the papapa2.vhd size is 25166336!=25165824 which means it's not aligned in MiB. + +could you please help? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1790617 b/results/classifier/accel-gemma3:12b/vmm/1790617 new file mode 100644 index 000000000..06d60ca76 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1790617 @@ -0,0 +1,44 @@ + +Version of disk image format not exhibited using the 'qemu-img info' command + +OS: Fedora (64 bits) – Linux –. Last available component: qemu-img.x86_64 2:2.11.2-2.fc28 + +Description: version of disk image format not exhibited using the 'qemu-img info' command. + +Command 'qemu-img info qcow2 [image-file-name.img]' produces this stderr message: +qemu-img: Expecting one image file name +Try 'qemu-img --help' for more information + +How to reproduce in terminal: +1. Create a VM using Raw disk image format +2. Run either commands 'qemu-img info -f raw [image-file-name.img]', 'qemu-img info [image-file-name.img]'. +3. Run either commands 'qemu-img info -f qcow2 [image-file-name.qcow2]', 'qemu-img info [image-file-name.qcow2]'. + +Actual result: output model resulting from step .2 exhibits following informations: +image: image-file-name.img +file format: raw +virtual size: _G (_ bytes) +disk size: _G + +Output model resulting from step .3 exhibits following informations: +image: image-file-name.qcow2 +file format: qcow2 +virtual size: _G (_ bytes) +disk size: _G +cluster_size: _ +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 snapshot1 _G 2018-07-31 18:27:49 00:03:45.890 + +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: false + +Actual result: raw and qcow2 formats respective versions –which are likely to be mentioned as "version"– to be exhibited. + +Additional information: in documentation lastly updated 2018-08-23 at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/index it is stated in chapters: + +14.10 – 'images in raw format can be resized in both directions, whereas qcow2 version 2 or qcow2 version 3 images can be grown'; +14.12 – 'the qcow2 version supplied with Red Hat Enterprise Linux 7 is 1.1', 'To know which version you are using, run qemu-img info qcow2 [imagefilename.img] command.'. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1793859 b/results/classifier/accel-gemma3:12b/vmm/1793859 new file mode 100644 index 000000000..d617c1eb9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1793859 @@ -0,0 +1,12 @@ + +GTK display and mouse input area scaling fails when using vfio-pci device + +Version qemu 3.0.0-1 running on Arch. Found on Windows 8.1 and Windows 10 VM's when using Intel gvt-g device. + +While in fullscreen the GTK display is scaled larger than the x11 screen or virtual machine resolution. Without choosing zoom-to-fit portions of the VM display are not shown on x11 screen regardless of the VM resolution. When zoom-to-fit is done the mouse that's shown on screen and actual input are off sync. The mouse can wander off screen when going left and down. + +This message is shown when changing from gxl-vga to vfio-pci in view menu. +(qemu-system-x86_64:6472): Gtk-WARNING **: 09:50:06.663: drawing failure for widget 'GtkDrawingArea': NULL pointer +(qemu-system-x86_64:6472): Gtk-WARNING **: 09:50:06.664: drawing failure for widget 'GtkNotebook': NULL pointer +(qemu-system-x86_64:6472): Gtk-WARNING **: 09:50:06.664: drawing failure for widget 'GtkBox': NULL pointer +(qemu-system-x86_64:6472): Gtk-WARNING **: 09:50:06.664: drawing failure for widget 'GtkWindow': NULL pointer \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1793904 b/results/classifier/accel-gemma3:12b/vmm/1793904 new file mode 100644 index 000000000..eb70ef4c5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1793904 @@ -0,0 +1,59 @@ + +files are randomly overwritten by Zero Bytes + +Hello together, + +I am currently tracking down a "Hard to reproduce" bug on my systems that I first discovered during gitlab installation: + + +Here is the Text from the Gitlab Bug https://gitlab.com/gitlab-org/gitlab-ce/issues/51023 +---------------------------------------------------------------------------------------------- + +Steps to reproduce + +I still do not have all the steps together to reproduce, so far it is: +apt install gitlab-ce and +gitlab-rake backup:recovery +Then it works for some time before it fails. + +What is the current bug behavior? + +I have a 12 hour old Installation of gitlab ce 11.2.3-ce.0 for debian stretch on a fresh debian stretch system together with our imported data. However it turns out that some gitlab related files contain Zero bytes instead of actual data. + +root@gitlab:~# xxd -l 16 /opt/gitlab/bin/gitlab-ctl +00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ + +This behaviour is somewhat strange because it was working for a few minutes/hours. I did write a shell script to find out which files are affected of this memory loss. It turns out that only files located under /opt/gitlab are affected, if I rule out files like /var/log/faillog and some postgresql table files. + +What I find even stranger is that it does not seem to affect Logfiles/databases/git_repositorys but application files, like .rb scripts. and not all of them. No non gitlab package is affected. + +What is the expected correct behavior? +Binarys and .rb files should stay as they are. + +Possible fixes + +I am still investigating, I hope that it is not an infrastructure problem (libvirt/qemu/glusterfs) it can still be one but the point that files of /opt/gitlab are affected and not any logfile and that we to not have similar problems with any other system leads me to the application for now. +If I would have used docker the same problem might have caused a reboot of the container. +But for the Debian package it is a bit of work to recover. That is all a workaround, however. +--------------------------------------------------------------------------------------------- + +I do have found 2 more systems having the same problem with different software: + +root@erp:~# xxd -l 16 /usr/share/perl/5.26.2/constant.pm +00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ + +The Filesize itself is, compared with another machine 00001660 Bytes for both the corrupted and the intact file. It looks to me from the outside that if some data in the qcow2 file is written too many bytes get written so it sometimes overwites data of existing files located right after the position in memory where the write goes to. + +I would like to rule out Linux+Ext4 filesystems because I find it highly unlikely that such an error keeps undiscovered in that part of the environment for long. I think the same might go for qemu. + +Which leaves qemu, gemu+gluster:// mount, qcow2 volumes, glusterfs, network. So I am now going to check if I can find any system which gets its volumes via fusermount instead of gluster:// path if the error is gone there. This may take a while. + + +----- some software versions--------------- + +QEMU emulator version 2.12.0 (Debian 1:2.12+dfsg-3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +libvirt-daemon-driver-storage-gluster/testing,unstable,now 4.6.0-2 amd64 [installed] + +ii glusterfs-client 4.1.3-1 amd64 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1794202 b/results/classifier/accel-gemma3:12b/vmm/1794202 new file mode 100644 index 000000000..53e6f8517 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1794202 @@ -0,0 +1,4 @@ + +Trying to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." + +When I try to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." Command ran in the command-line: "C:\Program Files\qemu\qemu-system-ppc" -L pc-bios -boot d -M mac99,via=pmu -m 512 -hda "C:\Users\*****\Downloads\macosx105\MacOSHDD.qcow2" -cdrom "C:\Users\*****\Downloads\macosx105\osx leopard install.iso" -netdev user,id=mynet0 -device sungem,netdev=mynet0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1795100 b/results/classifier/accel-gemma3:12b/vmm/1795100 new file mode 100644 index 000000000..8cd784053 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1795100 @@ -0,0 +1,33 @@ + +VNC unix-domain socket unlink()ed prematurely + +With qemu 3.0.0 (I don't believe this happened with previous +versions), if I tell it `-vnc unix:/path/to/vnc.sock`, qemu will +unlink() that file when the first client disconnects, meaning that +once I disconnect, I can't ever reconnect without restarting the VM. + +A stupid testcase demonstrating the issue: + +In terminal A: + + $ qemu-system-x86_64 -vnc unix:$PWD/vnc.sock + +In terminal B: + + $ ls vnc.sock + vnc.sock + $ socat STDIO UNIX-CONNECT:vnc.sock <<<'' + RFB 003.008 + $ ls vnc.sock + ls: cannot access 'vnc.sock': No such file or directory + +I have determined that the offending unlink() call is the one in +io/channel-socket.c:qio_channel_socket_close(). That call was first +introduced in commit d66f78e1eaa832f73c771d9df1b606fe75d52a50, which +first appeared in version 3.0.0. + +This type of premature unlink() does not happen on monitor.sock with +`-monitor unix:/path/to/monitor.sock,server,nowait`. + +I am not familiar enough with the QIO subsystem to suggest a fix that +fixes VNC, but preserves the QMP fix targeted in the offending commit. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1795527 b/results/classifier/accel-gemma3:12b/vmm/1795527 new file mode 100644 index 000000000..451c5b4b8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1795527 @@ -0,0 +1,68 @@ + +Malformed audio and video output stuttering after upgrade to QEMU 3.0 + +My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened kernel, running a few KVM guests with varying OSes and configurations managed through a Libvirt stack. + +Among these guests I have two Windows 10 VMs with VGA passthrough and PulseAudio-backed virtual audio devices. + +After upgrading to QEMU 3.0.0, both of the Win10 guests started showing corrupted audio output in the form of unnatural reproduction speed and occasional but consistently misplaced audio fragments originating from what seems to be a circular buffer wrapping over itself (misbehaviour detected by starting some games with known OSTs and dialogues: soundtracks sound accelerated and past dialogue lines start replaying middle-sentence until the next line starts playing). + +In addition, the video output of the malfunctioning VMs regularly stutters roughly twice a second for a fraction of a second (sync'ed with the suspected buffer wrapping and especially pronounced during not-pre-rendered cutscenes), toghether with mouse freezes that look like actual input misses more than simple lack of screen refreshes. + + +The issue was succesfully reproduced without the managing stack, directly with the following command line, on the most capable Windows guest: + + QEMU_AUDIO_DRV=pa + QEMU_PA_SERVER=127.0.0.1 + /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \ + -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \ + -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off \ + -drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \ + -m 5120 \ + -realtime mlock=off \ + -smp 3,sockets=1,cores=3,threads=1 \ + -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \ + -display none \ + -no-user-config \ + -nodefaults \ + -rtc base=localtime,driftfix=slew \ + -global kvm-pit.lost_tick_policy=delay \ + -no-hpet \ + -no-shutdown \ + -global PIIX4_PM.disable_s3=1 \ + -global PIIX4_PM.disable_s4=1 \ + -boot strict=on \ + -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \ + -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \ + -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \ + -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \ + -device ahci,id=sata0,bus=pci.0,addr=0x9 \ + -drive file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native \ + -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on \ + -drive file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \ + -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \ + -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \ + -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ + -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \ + -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \ + -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \ + -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ + -msg timestamp=on + + +By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" with "pc-i440fx-2.11" (basically reverting the config changes I needed to do in order to update the domain definitions), the stuttering seems to disappear (or at least becomes negligible) and the audio output, despite becoming incredibly distorted, is consistent in every other way, with in-order dialogues and (perceived) correct tempo. + + +In order to exclude eventual misconfigurations in the host's audio processing pipeline, I proceeded to update the domain definition's codepath of another guest running Ubuntu 18.04 with a completely different hardware configuration (no video card passthrough and no PulseAudio backconnection, just a plain emulated VirtIO display and Spice audio device). + +The audio issue presented itself again in the form of slightly sped up audio playback from Internet videos interleaved with occasional "quenches" of playing speed. +Stutters are difficult to detect because of the poor refresh rate of the emulated VGA adapter, but I wouldn't be surprised to find them here too (actually, I *think* I sensed them, but I'm not sure enough to assess their existence). + +Once again, by reverting to the old 2.11 directive everything is back to normal. + + + +Given the fact that no official upgrade directives regarding required sampling rate, period or sheduling adjustments were stated or handed-out to administrators, I decided to report this behaviour as a bug. +I hope this is the appropriate channel and that I didn't annoy anyone (this is my first proper bug report, please forgive me for any innaccuracy). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1798451 b/results/classifier/accel-gemma3:12b/vmm/1798451 new file mode 100644 index 000000000..1afa18b7b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1798451 @@ -0,0 +1,34 @@ + +MMX emulation is missing on HVF Acceleration + + +Robs-MacBook-Pro-2:~ robmaskell$ qemu-system-x86_64 --version +QEMU emulator version 3.0.0 + +Host: MacOS - 10.13.6 + Model Name: MacBook Pro + Model Identifier: MacBookPro14,3 + Processor Name: Intel Core i7 + Processor Speed: 2.8 GHz + Number of Processors: 1 + Total Number of Cores: 4 + L2 Cache (per Core): 256 KB + L3 Cache: 6 MB + Memory: 16 GB + +Guest OS: Elementary Linux Loki 0.4.1, patched up to date + +Command used to start QEMU: + +qemu-system-x86_64 \ + -name ElementaryLokiDev \ + -machine pc,accel=hvf \ + -cpu max \ + -smp cpus=2,sockets=2,cores=1,threads=1,maxcpus=2 \ + -numa node,nodeid=0 \ + -numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=0,socket-id=1 \ + -m 8G \ + -vga vmware \ + -hda e4.qcow2 + +Symptoms: Started without the -smp / -numa commands to install the OS, then added -smp / -numa and the machine boots and lscpu reports extra cpu as expected. Restart VM and it hangs on startup. Remove -smp / -numa and machine starts again. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1799766 b/results/classifier/accel-gemma3:12b/vmm/1799766 new file mode 100644 index 000000000..086a2b5c7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1799766 @@ -0,0 +1,196 @@ + +-device does not work as -drive do + +Copy/paste of https://stackoverflow.com/questions/52929723/qemu-eject-complains-device-is-not-found-while-it-is-there , since I found this bug trying to find an answer to an own question on Stack Overflow. + +Below, what was my question the answer I wrote, all exposes the bug. + +==================================================================== + + +I need to eject a floppy from QEmu 3.0 monitor, but the command surprisingly fails complaining the device is not found, while it is really there. + +Listing of devices: + + (qemu) info block + fda: dos-6-22/Dos622-1.img (raw) + Attached to: /machine/unattached/device[11] + Removable device: not locked, tray closed + Cache mode: writeback + + hda: hda.img (raw) + Attached to: /machine/peripheral-anon/device[1] + Cache mode: writeback + +Eject command result: + + (qemu) eject fda + Device 'fda' not found + +This is so although this documentation says this is how I have to do: https://www.linux-kvm.org/page/Change_cdrom (just that I want to eject the floppy instead of the CD‑ROM). + +The `change` command complains the same: + + (qemu) change fda dos-6-22/Dos622-2.img raw + Device 'fda' not found + +Is this a bug or me doing something wrong? + +I tried using different node names, with always the same result. + +==================================================================== + +I’m posting as an answer, but I’m not strictly sure. I can just say, if I understand correctly, this is a bug. + +The answer comes in two parts. + +First part, is a stripped down failing invocation: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img \ + -global isa-fdc.driveA=fda + + (qemu) info block + ide1-cd0: [not inserted] + Attached to: /machine/unattached/device[19] + Removable device: not locked, tray closed + + sd0: [not inserted] + Removable device: not locked, tray closed + + fda: fda.img (raw) + Attached to: /machine/unattached/device[13] + Removable device: not locked, tray closed + Cache mode: writeback + (qemu) eject fda + Device 'fda' not found + +Second part, is the same without the last argument `-global isa-fdc.driveA=fda`: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img + + (qemu) info block + ide1-cd0: [not inserted] + Attached to: /machine/unattached/device[19] + Removable device: not locked, tray closed + + floppy0: [not inserted] + Attached to: /machine/unattached/device[13] + Removable device: not locked, tray closed + + sd0: [not inserted] + Removable device: not locked, tray closed + (qemu) eject floppy0 + +There is more error when `-global isa-fdc.driveA=fda` is removed. However, the documentation says: + +> -global driver=driver,property=property,value=value +> Set default value of driver’s property prop to value, e.g.: + +> qemu-system-i386 -global ide-hd.physical_block_size=4096 disk-image.img +> In particular, you can **use this to set driver properties for devices which are created automatically by the machine model**. To create a device which is not created automatically and set properties on it, use -device. + +> -global driver.prop=value is shorthand for -global driver=driver,property=prop,value=value. The longhand syntax works even when driver contains a dot. + +What I put a stress on in the quote, suggest I’m not misusing `-global` and that’s most probably a bug. + +**Update for more details:** + +It seems using `-drive` instead of `-device` and `driveA` assignment, the result is not the same, although RedHat documentation recommands using `-device` instead of `-drive` and QEmu 3.0 documentation says `-drive` is essentially a shortcut for `-device` (“essentially”, not telling about the difference). + +Below, two cases, with an except of `info block` and an excerpt of `info qtree`. + +With this one, `eject floppy0` works: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -drive format=raw,if=floppy,media=disk,file=fda.img \ + -device isa-vga,vgamem_mb=1 \ + -serial msmouse + + […] + + floppy0 (#block156): fda.img (raw) + Attached to: /machine/unattached/device[12] + Removable device: not locked, tray closed + Cache mode: writeback + + […] + + dev: isa-fdc, id "" + iobase = 1008 (0x3f0) + irq = 6 (0x6) + dma = 2 (0x2) + driveA = "" + driveB = "" + check_media_rate = true + fdtypeA = "auto" + fdtypeB = "auto" + fallback = "288" + isa irq 6 + bus: floppy-bus.0 + type floppy-bus + dev: floppy, id "" + unit = 0 (0x0) + drive = "floppy0" + logical_block_size = 512 (0x200) + physical_block_size = 512 (0x200) + min_io_size = 0 (0x0) + opt_io_size = 0 (0x0) + discard_granularity = 4294967295 (0xffffffff) + write-cache = "auto" + share-rw = false + drive-type = "144" + +With this one, `eject fda` does not work: + + qemu-system-i386 \ + -monitor stdio \ + -machine type=isapc,vmport=off \ + -blockdev driver=file,node-name=fda-img,filename=fda.img \ + -blockdev driver=raw,node-name=fda,file=fda-img \ + -global isa-fdc.driveA=fda \ + -device isa-vga,vgamem_mb=1 \ + -serial msmouse + + […] + + fda: fda.img (raw) + Attached to: /machine/unattached/device[12] + Removable device: not locked, tray closed + Cache mode: writeback + + […] + + dev: isa-fdc, id "" + iobase = 1008 (0x3f0) + irq = 6 (0x6) + dma = 2 (0x2) + driveA = "" + driveB = "" + check_media_rate = true + fdtypeA = "auto" + fdtypeB = "auto" + fallback = "288" + isa irq 6 + bus: floppy-bus.0 + type floppy-bus + dev: floppy, id "" + unit = 0 (0x0) + drive = "fda" + logical_block_size = 512 (0x200) + physical_block_size = 512 (0x200) + min_io_size = 0 (0x0) + opt_io_size = 0 (0x0) + discard_granularity = 4294967295 (0xffffffff) + write-cache = "auto" + share-rw = false + drive-type = "144" \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1799792 b/results/classifier/accel-gemma3:12b/vmm/1799792 new file mode 100644 index 000000000..246a31376 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1799792 @@ -0,0 +1,13 @@ + +Broken scaling with gtk,gl=on on a hidpi display + +Tested on QEMU 3.0.0 on Arch Linux. + +I'm using a hidpi screen, and therefore use those environment variables in order to have GTK+ apps properly scaled: + +GDK_SCALE=2 +GDK_DPI_SCALE=0.5 + +However, QEMU, when launched with "-display gtk,gl=on" option, doesn't scale the window content properly, as seen on the attached screenshot. + +Switching to "-display gtk,gl=off" and "-display sdl,gl=on" makes it work fine. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1800401 b/results/classifier/accel-gemma3:12b/vmm/1800401 new file mode 100644 index 000000000..5027c33e8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1800401 @@ -0,0 +1,30 @@ + +efifb on Linux guest fails to load when using VGA passthrough + +The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. + +Steps to Reproduce: + 1. Install qemu and ovmf + 2. Download systemrescuecd-x86-5.3.1.iso + 3. Run qemu using one of the configurations below + 4. Select first boot option in GRUB menu + 5. Wait 30 seconds + 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 + 7. Wait 2 minutes + 8. Observe fb console + 9. Note lack of output until very late in boot process + 10. Check dmesg + 11. Note efifb failed to load (invalid address) + 12. Note nouveaufb started late in boot process + +Expected Results: + The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. + +Actual Results: + The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. + +Additional information: + +Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 + +I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1800993 b/results/classifier/accel-gemma3:12b/vmm/1800993 new file mode 100644 index 000000000..8dfa3d577 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1800993 @@ -0,0 +1,10 @@ + +How to Migration VM Built on Qemu Souce Code Installation + +Respected all, + +I followed https://wiki.qemu.org/Hosts/Linux to build qemu from source code. Its installed successfully with Ubuntu 16.04 VM created using VNC server. + +Now, Could you please suggest me how to migrate VM from one host to another?. + +Email: <email address hidden> \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1802465 b/results/classifier/accel-gemma3:12b/vmm/1802465 new file mode 100644 index 000000000..cdb9ace58 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1802465 @@ -0,0 +1,28 @@ + +typing string via VNC is unreliable + +QEMU version is 3.0.0 + +# Description + +The problem is that, when typing string through VNC, it can be unreliable -- sometimes some key strokes get skipped, sometimes get swapped, sometimes get repeated. There's no problem when typing through VNC on physical hardware. + +# Steps to reproduce + +1. Launch virtual machine by: + + qemu-kvm -display vnc=:1 -m 2048 opensuse-leap-15.qcow2 + +2. Connect to VNC by: + + vncviewer -Shared :5901 + +3. Simulate a series of key strokes by "vncdotool" [1]: + + vncdotool -s 127.0.0.1::5901 typefile strings_to_be_typed.txt + +4. Usually after a few hundred keys are typed, something goes wrong. + +I attached a screenshot that it mistypes " hello" to "h ello". + +[1] https://github.com/sibson/vncdotool \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1806040 b/results/classifier/accel-gemma3:12b/vmm/1806040 new file mode 100644 index 000000000..531c2bcc5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1806040 @@ -0,0 +1,16 @@ + +Nested VMX virtualization error on last Qemu versions + +Recently updated Qemu on a Sony VAIO sve14ag18m with Ubuntu Bionic 4.15.0-38 from Git + +After launching a few VMs, noticed that i could not create Snapshot due to this error: +"Nested VMX virtualization does not support live migration yet" + +I've created a new Windows 7 X64 machine with this compilation of Qemu and the problem persisted, so it's not because of the old machines. + +I launch Qemu with this params (I use them for malware analisys adn re...): +qemu-system-x86_64 -monitor stdio -display none -m 4096 -smp cpus=4 -usbdevice tablet -drive file=VM.img,index=0,media=disk,format=qcow2,cache=unsafe -net nic,macaddr="...." -net bridge,br=br0 -cpu host,-hypervisor,kvm=off -vnc 127.0.0.1:0 -enable-kvm + + +Deleting the changes made on this commit solved the problem, but I dont have idea what is this for, so... xDD +https://github.com/qemu/qemu/commit/d98f26073bebddcd3da0ba1b86c3a34e840c0fb8 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1808824 b/results/classifier/accel-gemma3:12b/vmm/1808824 new file mode 100644 index 000000000..e76b55199 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1808824 @@ -0,0 +1,8 @@ + +Mouse leaves VM window when Grab on Hover isn't selected Windows 10 and Intel HAX + +On Windows 10.0.17134 I have been having the problem that the mouse will leave the VM window after a short time when grab on hover isn't selected. The VM will then try to grab on Hover and the mouse will grab in weird places and it will become very unwieldy to control the mouse in the VM window. + +This is exasperated by super slow response making it nearly unusable if the Intel® Hardware Accelerated Execution Manager (Intel® HAXM) is not currently installed on my machine. + +I know they are different things but they compounded on each other when you have a mouse that is not staying in the VM window and the VM's visualized cpu is acting VERY slow the system is unusable. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1809 b/results/classifier/accel-gemma3:12b/vmm/1809 new file mode 100644 index 000000000..993c2c615 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1809 @@ -0,0 +1,54 @@ + +config machine "virt-6.2" with qemu-system-aarch64,it report "mem is not supported by this machine type" +Description of problem: +When i config the machine with virt-6.2 and config the numa for cpu,it report "mem is not supported by this machine type",but with virt-5.0 it work well,the newer version virt not support it? It is bug or require hardware support?Or compile configure is not correctlly? + +when i create vm,get the error report as follow: + +virsh create test.xml +``` +qemu unexpectedly closed the monitor: qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'server' deprecated +Please use server=on instead +qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'nowait' deprecated +Please use wait=off instead +configure accelerator virt-6.2 start +machine init start +2023-08-04T02:17:13.984797Z qemu-system-aarch64: -numa node,nodeid=0,cpus=0-3,mem=8192: Parameter -numa node,mem is not supported by this machine type +Use -numa node,memdev instead + +``` + + +I use qmp command "query-machines" get the result as follow: +``` +{ + "hotpluggable-cpus": true, + "name": "virt-6.2", + ** "numa-mem-supported": false,** + "default-cpu-type": "cortex-a15-arm-cpu", + "cpu-max": 512, + "deprecated": false, + "default-ram-id": "mach-virt.ram", + "alias": "virt" + }, +``` + +I add the code "mc->numa_mem_supported = true;" in the api "virt_machine_6_1_options",it can supoort numa,but i don't know whether it is affected. + +``` +DEFINE_VIRT_MACHINE_AS_LATEST(6, 2) + +static void virt_machine_6_1_options(MachineClass *mc) +{ + VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc)); + + virt_machine_6_2_options(mc); + compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len); + mc->smp_props.prefer_sockets = true; + vmc->no_cpu_topology = true; + **mc->numa_mem_supported = true;** + + /* qemu ITS was introduced with 6.2 */ + vmc->no_tcg_its = true; +} +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1809252 b/results/classifier/accel-gemma3:12b/vmm/1809252 new file mode 100644 index 000000000..64d1769f9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1809252 @@ -0,0 +1,8 @@ + +Password authentication in FIPS-compliant mode + +The documentation states, that: + +"The VNC protocol has limited support for password based authentication. (...) Password authentication is not supported when operating in FIPS 140-2 compliance mode as it requires the use of the DES cipher." + +Would it be possible for qemu to use a different cipher and re-enable password as an option in VNC console? Is there a technical reason for not using a stronger cipher? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1809453 b/results/classifier/accel-gemma3:12b/vmm/1809453 new file mode 100644 index 000000000..1e5622980 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1809453 @@ -0,0 +1,8 @@ + +Windows qemu download Big file bug in net user mode + +hi + +Windows qemu with -net user downloading big files has a bug, -net tap is good! + +I suspect that the Slirp protocol has a bug on the Windows pc, which is normal on ubuntu. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1810105 b/results/classifier/accel-gemma3:12b/vmm/1810105 new file mode 100644 index 000000000..1f5f87032 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1810105 @@ -0,0 +1,24 @@ + +Hint showing volume never disappears, blocking buttons to minimize, maximize and close + +When hovering the mouse over the volume indicator or changing its volume using the mouse wheel it shows the current volume set as a hint. For example: + +Volume 100% + +The problem is that the hint never disappears, not even clicking on it. On some occasions the hint can cover the minimize, maximize and close buttons, causing significant problems on using the desktop environment, as these three buttons won't be usable anymore with the hint over it. + +Where the hint appears it's no longer possible to interact with the screen. + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: xfce4-pulseaudio-plugin 0.4.1-0ubuntu1 +ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18 +Uname: Linux 4.15.0-43-generic x86_64 +ApportVersion: 2.20.9-0ubuntu7.5 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Sun Dec 30 17:09:23 2018 +InstallationDate: Installed on 2018-12-30 (0 days ago) +InstallationMedia: Xubuntu 18.04.2 LTS "Bionic Beaver" - Beta amd64 (20181230) +SourcePackage: xfce4-pulseaudio-plugin +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1811533 b/results/classifier/accel-gemma3:12b/vmm/1811533 new file mode 100644 index 000000000..a2a5e888e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1811533 @@ -0,0 +1,32 @@ + +Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer + +Host: +Gentoo linux x86_64, kernel 4.20.1 +Qemu 3.1.0 +CPU: Intel i7 6850K +Chipset: X99 + +Guest: +Windows 10 Pro 64bit (1809) +Machine type: pc-q35_3.1 +Hyper-V enlightenments: hv_stimer,hv_reenlightenment,hv_frequencies,hv_vapic,hv_reset,hv_synic,hv_runtime,hv_vpindex,hv_time,hv_relaxed,hv_spinlocks=0x1fff +Memory: 16GB backed by 2MB huge pages + +Issue: +Once guest is started, log gets flooded with: + +qemu-system-x86_64: vhost_region_add_section: Overlapping but not coherent sections at 103000 + +or + +qemu-system-x86_64: vhost_region_add_section:Section rounded to 0 prior to previous 1f000 + +(line endings change) + +and as time goes guest loses network access (virtio-net-pci) and general performance diminishes to extent of freezing applications. + +Observations: +1) problem disappears when hv_stimer is removed +2) problem disappears when memory backing with huge pages is disabled +3) problem disappears when machine type is downgraded to pc-q35_3.0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1811543 b/results/classifier/accel-gemma3:12b/vmm/1811543 new file mode 100644 index 000000000..5fb1811b5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1811543 @@ -0,0 +1,73 @@ + +virtio-scsi gives improper discard sysfs entries + +Apologies if this is just an inherent part of paravirtualization that should be expected. + +In my host, I have an LVM thin pool with chunk_size 128MB. Within it, I have a thin volume "tmp". In the host: + +# fdisk -l /dev/lvm/tmp +Disk /dev/lvm/tmp: 256 MiB, 268435456 bytes, 524288 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 262144 bytes / 134217728 bytes +Disklabel type: gpt +Disk identifier: BAE3154E-6E85-F642-8129-BAD7B58B2775 + +Device Start End Sectors Size Type +/dev/lvm/tmp1 2048 524254 522207 255M Linux filesystem + +$ lsblk +... + └─lvm-tmp 254:13 0 256M 0 lvm + └─lvm-tmp1 254:14 0 255M 0 part + +$ cat /sys/dev/block/254:13/discard_alignment +0 +$ cat /sys/dev/block/254:13/queue/discard_granularity +134217728 +$ cat /sys/dev/block/254:13/queue/discard_max_bytes +17179869184 +$ cat /sys/dev/block/254:13/queue/discard_max_hw_bytes +0 +$ cat /sys/dev/block/254:13/queue/discard_zeroes_data +0 + +$ cat /sys/dev/block/254:14/discard_alignment +133169152 +$ cat /sys/dev/block/254:14/queue/discard_granularity +134217728 +$ cat /sys/dev/block/254:14/queue/discard_max_bytes +17179869184 +$ cat /sys/dev/block/254:14/queue/discard_max_hw_bytes +0 +$ cat /sys/dev/block/254:14/queue/discard_zeroes_data +0 + +If this is given to QEMU using virtio-scsi: + + -device virtio-scsi-pci,id=scsi1 \ + -drive driver=raw,node-name=hdb,file=/dev/lvm/tmp,if=none,discard=unmap,id=hd2 \ + -device scsi-hd,drive=hd2,bootindex=1 \ + +Then incorrect values are given: + +$ lsblk +... +sdb 8:16 0 256M 0 disk +└─sdb1 8:17 0 255M 0 part /mnt + +$ cat /sys/dev/block/8:16/discard_alignment +0 +$ cat /sys/dev/block/8:16/queue/discard_granularity +4096 +$ cat /sys/dev/block/8:16/queue/discard_max_bytes +1073741824 +$ cat /sys/dev/block/8:16/queue/discard_max_hw_bytes +1073741824 +$ cat /sys/dev/block/8:16/queue/discard_zeroes_data +0 + +$ cat /sys/dev/block/8:17/discard_alignment +133169152 + +And, there isn't even a /sys/dev/block/8:17/queue direcotry. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1811758 b/results/classifier/accel-gemma3:12b/vmm/1811758 new file mode 100644 index 000000000..40ff77177 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1811758 @@ -0,0 +1,6 @@ + +virtio-rng backend should use getentropy() syscall when available + +According to https://wiki.qemu.org/Features/VirtIORNG the default backend for `virtio-rng-pci` is `/dev/random`. Alternately, the user can point it to a different backend file, like `/dev/urandom`. + +However, both of these files have suboptimal behavior in one way or another, as documented in `random(7)`. Instead, the default behavior should be to pull the requested octets from the `getrandom()` system call, if available, called with no flags set. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1813045 b/results/classifier/accel-gemma3:12b/vmm/1813045 new file mode 100644 index 000000000..b265cdc5f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1813045 @@ -0,0 +1,17 @@ + +qemu-ga fsfreeze crashes the kernel + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +I believe this is the culprit: + +/dev/loop0 /tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0 +/dev/loop0 /var/tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1815 b/results/classifier/accel-gemma3:12b/vmm/1815 new file mode 100644 index 000000000..1ce6f2771 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1815 @@ -0,0 +1,83 @@ + +Null pointer access in nvme_directive_receive() +Description of problem: +Got an access within null pointer error when fuzzing nvme. +Steps to reproduce: +Minimized reproducer for the error: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 \ +-nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device \ +nvme,drive=disk0,serial=1 -qtest /dev/null -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +write 0xe0000024 0x4 0x040002 +write 0xe0000014 0x4 0x61004600 +write 0xe0001000 0x1 0x04 +write 0x0 0x1 0x1a +write 0x4 0x1 0x01 +write 0x2c 0x1 0x01 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +[I 0.000000] OPENED +[R +0.025407] outl 0xcf8 0x80000810 +[S +0.025443] OK +OK +[R +0.025456] outl 0xcfc 0xe0000000 +[S +0.025470] OK +OK +[R +0.025476] outl 0xcf8 0x80000804 +[S +0.025483] OK +OK +[R +0.025489] outw 0xcfc 0x06 +[S +0.025934] OK +OK +[R +0.025946] write 0xe0000024 0x4 0x040002 +[S +0.025958] OK +OK +[R +0.025964] write 0xe0000014 0x4 0x61004600 +[S +0.025988] OK +OK +[R +0.026025] write 0xe0001000 0x1 0x04 +[S +0.026041] OK +OK +[R +0.026048] write 0x0 0x1 0x1a +[S +0.026256] OK +OK +[R +0.026268] write 0x4 0x1 0x01 +[S +0.026279] OK +OK +[R +0.026292] write 0x2c 0x1 0x01 +[S +0.026303] OK +OK +../hw/nvme/ctrl.c:6890:29: runtime error: member access within null pointer of type 'NvmeEnduranceGroup' (aka 'struct NvmeEnduranceGroup') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/nvme/ctrl.c:6890:29 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==1085476==ERROR: AddressSanitizer: SEGV on unknown address 0x000000001fc8 (pc 0x56306b765ebf bp 0x7ffff17fd890 sp 0x7ffff17f6a00 T0) +==1085476==The signal is caused by a READ memory access. + #0 0x56306b765ebf in nvme_directive_receive ../hw/nvme/ctrl.c:6890:33 + #1 0x56306b765ebf in nvme_admin_cmd ../hw/nvme/ctrl.c:6958:16 + #2 0x56306b765ebf in nvme_process_sq ../hw/nvme/ctrl.c:7015:13 + #3 0x56306cda2c3b in aio_bh_call ../util/async.c:169:5 + #4 0x56306cda3384 in aio_bh_poll ../util/async.c:216:13 + #5 0x56306cd3f15b in aio_dispatch ../util/aio-posix.c:423:5 + #6 0x56306cda72da in aio_ctx_dispatch ../util/async.c:358:5 + #7 0x7fa321cc417c in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5217c) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561) + #8 0x56306cda840f in glib_pollfds_poll ../util/main-loop.c:290:9 + #9 0x56306cda840f in os_host_main_loop_wait ../util/main-loop.c:313:5 + #10 0x56306cda840f in main_loop_wait ../util/main-loop.c:592:11 + #11 0x56306bd17f76 in qemu_main_loop ../softmmu/runstate.c:732:9 + #12 0x56306c721835 in qemu_default_main ../softmmu/main.c:37:14 + #13 0x7fa320aeb082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #14 0x56306af0309d in _start (./qemu-system-x86_64+0x1e9109d) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV ../hw/nvme/ctrl.c:6890:33 in nvme_directive_receive +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1815009 b/results/classifier/accel-gemma3:12b/vmm/1815009 new file mode 100644 index 000000000..6eec684fc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1815009 @@ -0,0 +1,8 @@ + +Qemu evdev multiple guests/host switch + +Hello, + +Qemu up to version 3.1 + +it would be nice if passed through evdev can be switched (using lctrl + rctrl) through all running guests configured for evdev and the host. Currently, only the last started guest and host can be switched only so the previously started guests can't be controlled. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1815263 b/results/classifier/accel-gemma3:12b/vmm/1815263 new file mode 100644 index 000000000..46c575f0b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1815263 @@ -0,0 +1,103 @@ + +hvf accelerator crashes on quest boot + +Host OS: macOS High Sierra (10.13.6) +MacBook Pro (Retina, Mid 2015) +Processor: 2.8GHz Intel Core i7 +Guest OS: OpenBSD 6.4 install media (install64.iso) +Qemu 3.1.0 release, built with: +./configure --prefix=/usr/local/Cellar/qemu/3.1.0_1 --cc=clang + --host-cc=clang + --disable-bsd-user + --disable-guest-agent + --enable-curses + --enable-libssh2 + --enable-vde + --extra-cflags=-DNCURSES_WIDECHAR=1 + --enable-cocoa + --disable-sdl + --disable-gtk + --enable-hvf + --target-list=x86_64-softmmu + --enable-debug + +I invoke qemu like this: +Last command had exit code: 0 at 22:58 +nwallace@nwallace-ltm3:~ +$ sudo qemu-system-x86_64 -M accel=hvf -boot d -cdrom ~/Downloads/install64.iso +Password: +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +bad size + +Abort trap: 6 +Last command had exit code: 134 at 22:58 +nwallace@nwallace-ltm3:~ +$ + +I ran qemu in lldb to get a stack trace and I get: +Last command had exit code: 0 at 22:54 +nwallace@nwallace-ltm3:~/Downloads +$ sudo lldb -- qemu-system-x86_64 -M accel=hvf -boot d -cdrom /Users/nwallace/Downloads/install64.iso +Password: +(lldb) target create "qemu-system-x86_64" +Current executable set to 'qemu-system-x86_64' (x86_64). +(lldb) settings set -- target.run-args "-M" "accel=hvf" "-boot" "d" "-cdrom" "/Users/nwallace/Downloads/install64.i +so" +(lldb) run +Process 96474 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64) +Process 96474 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR2 + frame #0: 0x00007fff5ef0c00a libsystem_kernel.dylib`__sigsuspend + 10 +libsystem_kernel.dylib`__sigsuspend: +-> 0x7fff5ef0c00a <+10>: jae 0x7fff5ef0c014 ; <+20> + 0x7fff5ef0c00c <+12>: movq %rax, %rdi + 0x7fff5ef0c00f <+15>: jmp 0x7fff5ef02b0e ; cerror + 0x7fff5ef0c014 <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) process handle SIGUSR1 -n true -p true -s false +NAME PASS STOP NOTIFY +=========== ===== ===== ====== +SIGUSR1 true false true +(lldb) process handle SIGUSR2 -n true -p true -s false +NAME PASS STOP NOTIFY +=========== ===== ===== ====== +SIGUSR2 true false true +(lldb) c +Process 96474 resuming +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +Process 96474 stopped and restarted: thread 9 received signal: SIGUSR2 +<line above repeats about 64 times or so> +Process 96474 stopped and restarted: thread 9 received signal: SIGUSR2 +bad size + +Process 96474 stopped +* thread #9, stop reason = signal SIGABRT + frame #0: 0x00007fff5ef0bb66 libsystem_kernel.dylib`__pthread_kill + 10 +libsystem_kernel.dylib`__pthread_kill: +-> 0x7fff5ef0bb66 <+10>: jae 0x7fff5ef0bb70 ; <+20> + 0x7fff5ef0bb68 <+12>: movq %rax, %rdi + 0x7fff5ef0bb6b <+15>: jmp 0x7fff5ef02ae9 ; cerror_nocancel + 0x7fff5ef0bb70 <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #9, stop reason = signal SIGABRT + * frame #0: 0x00007fff5ef0bb66 libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007fff5f0d6080 libsystem_pthread.dylib`pthread_kill + 333 + frame #2: 0x00007fff5ee671ae libsystem_c.dylib`abort + 127 + frame #3: 0x000000010016b6ec qemu-system-x86_64`exec_cmps_single + 400 + frame #4: 0x000000010016ada4 qemu-system-x86_64`exec_cmps + 65 + frame #5: 0x0000000100169aaa qemu-system-x86_64`exec_instruction + 48 + frame #6: 0x0000000100164eb2 qemu-system-x86_64`hvf_vcpu_exec + 2658 + frame #7: 0x000000010005bed6 qemu-system-x86_64`qemu_hvf_cpu_thread_fn + 200 + frame #8: 0x00000001003ee531 qemu-system-x86_64`qemu_thread_start + 107 + frame #9: 0x00007fff5f0d3661 libsystem_pthread.dylib`_pthread_body + 340 + frame #10: 0x00007fff5f0d350d libsystem_pthread.dylib`_pthread_start + 377 + frame #11: 0x00007fff5f0d2bf9 libsystem_pthread.dylib`thread_start + 13 +(lldb) quit +Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] Y +Last command had exit code: 0 at 23:01 +nwallace@nwallace-ltm3:~/Downloads +$ + + +I'm happy to work with someone more knowledgeable to reproduce this issue and provide debugging assistance as I'm able. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1815413 b/results/classifier/accel-gemma3:12b/vmm/1815413 new file mode 100644 index 000000000..4a6c130e4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1815413 @@ -0,0 +1,28 @@ + +compile with vhost-vsock support on osx + +compiling latest (3.1.0) on osx 10.14.3 with --enable-vhost-vsock and target = x86_64-softmmu results in compile errors: + +Undefined symbols for architecture x86_64: + "_vhost_dev_cleanup", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + _vhost_vsock_device_unrealize in vhost-vsock.o + "_vhost_dev_disable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_enable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_init", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + "_vhost_dev_start", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_stop", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_virtqueue_mask", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + _vhost_vsock_guest_notifier_mask in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_mask) + "_vhost_virtqueue_pending", referenced from: + _vhost_vsock_guest_notifier_pending in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_pending) +ld: symbol(s) not found for architecture x86_64 +clang: error: linker command failed with exit code 1 (use -v to see invocation) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1816 b/results/classifier/accel-gemma3:12b/vmm/1816 new file mode 100644 index 000000000..63ede946f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1816 @@ -0,0 +1,75 @@ + +Memory size limitation under podman on Apple silicon +Description of problem: +We are using latest MacOS (Ventura) on M2 Ultra with 128Gb RAM (Mac Studio) to run our product Linux aarch64 builds in podman containers. This is cheaper than buying ARM server hardware, and we are not able to use cloud services. + +The issue arises when we try to use the available RAM for the underlying QEMU machine. There seems to be a memory limit which looks like it is in QEMU not podman machine, since that is more of a wrapper in this process. + +The use case is to init a Fedora Linux VM by QEMU which provides a Linux kernel. That kernel is then used to run podman containers. + +When we set the memory limit to 64513Mb the podman machine (VM) start fails with "Error: HV_BAD_ARGUMENT". If we reduce the memory limit to "64512" it works as expected. + +This is an example of how to reproduce: + +` +macstudio:~ build $ podman machine init --cpus="18" --memory="64513" podman-machine-default +Extracting compressed file +Image resized. +Machine init complete +To start your machine run: + +podman machine start + +macstudio:~ build $ podman machine start +Starting machine "podman-machine-default" +Waiting for VM ... +Error: qemu exited unexpectedly with exit code -1, stderr: qemu-system-aarch64: Error: HV_BAD_ARGUMENT + +macstudio:~ build $ podman machine rm --force +macstudio:~ build $ podman machine init --cpus="18" --memory="64512" podman-machine-default +Extracting compressed file +Image resized. +Machine init complete +To start your machine run: + +podman machine start + +macstudio:~ build $ podman machine start +Starting machine "podman-machine-default" +Waiting for VM ... +Mounting volume... /Users:/Users +Mounting volume... /private:/private +Mounting volume... /var/folders:/var/folders + +This machine is currently configured in rootless mode. If your containers +require root permissions (e.g. ports < 1024), or if you run into compatibility +issues with non-podman clients, you can switch using the following command: + +podman machine set --rootful + +API forwarding listening on: /Users/build_ci/.local/share/containers/podman/machine/qemu/podman.sock + +The system helper service is not installed; the default Docker API socket +address can't be used by podman. If you would like to install it run the +following commands: + +sudo /opt/homebrew/Cellar/podman/4.6.0/bin/podman-mac-helper install +podman machine stop; podman machine start + +You can still connect Docker API clients by setting DOCKER_HOST using the +following command in your terminal session: + +export DOCKER_HOST='unix:///Users/build/.local/share/containers/podman/machine/qemu/podman.sock' + +Machine "podman-machine-default" started successfully +macstudio:~ build $ podman machine ls +NAME VM TYPE CREATED LAST UP CPUS MEMORY DISK SIZE +podman-machine-default* qemu About a minute ago Currently running 18 63GiB 100GiB + +` +Steps to reproduce: +1. Initialise the VM with a RAM limit of 64513Mb, then start it. +2. +3. +Additional information: +Feel free to ask for more information. Unfortunately, these machines are our production platform, so further testing will not have a rapid turn around. We are open to taking a machine out of production for testing, it just needs scheduling. diff --git a/results/classifier/accel-gemma3:12b/vmm/1816805 b/results/classifier/accel-gemma3:12b/vmm/1816805 new file mode 100644 index 000000000..47a020d26 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1816805 @@ -0,0 +1,13 @@ + +Cannot create cdrom device with open tray and cache option + +When trying to create cdrom device with open tray and either of "cache" or "discard" options specified, I get the following error: + +qemu-system-x86_64: -drive if=none,id=drive-ide0-0-0,readonly=on,cache=writeback,discard=unmap,throttling.iops-total=900: Must specify either driver or file + +This bug essentially forbids live migration of VMs with open cdrom trays. + +I was able to find the same bug at RedHat: +https://bugzilla.redhat.com/show_bug.cgi?id=1338638 + +The bug was encountered in versions 2.5 and 2.11. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1816819 b/results/classifier/accel-gemma3:12b/vmm/1816819 new file mode 100644 index 000000000..a39dde822 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1816819 @@ -0,0 +1,52 @@ + +Chardev websocket stops listening after first connection disconnects + +Using qemu option: + -chardev socket,id=websock0,websocket,port=13042,host=127.0.0.1,server,nowait -serial chardev:websock0 + +To have a websocket listening chardev. After the first connection disconnects (that does a full websocket handshake), subsequent connections aren't accepted. See below for a reproducing session kindly provided by Daniel: + +$ telnet localhost 13042 +Trying ::1... +telnet: connect to address ::1: Connection refused +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +GET / HTTP/1.1 +Upgrade: websocket +Connection: Upgrade +Host: localhost:%s +Origin: http://localhost +Sec-WebSocket-Key: o9JHNiS3/0/0zYE1wa3yIw== +Sec-WebSocket-Version: 13 +Sec-WebSocket-Protocol: binary + +HTTP/1.1 101 Switching Protocols +Server: QEMU VNC +Date: Wed, 20 Feb 2019 16:52:04 GMT +Upgrade: websocket +Connection: Upgrade +Sec-WebSocket-Accept: b3DnPh7O8hyYE5sIjQxl/c1J+S8= +Sec-WebSocket-Protocol: binary + +sfsd +�&�only binary frames may be fragmentedConnection closed by foreign host. + +$ telnet localhost 13042 +Trying ::1... +telnet: connect to address ::1: Connection refused +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +GET / HTTP/1.1 +Upgrade: websocket +Connection: Upgrade +Host: localhost:%s +Origin: http://localhost +Sec-WebSocket-Key: o9JHNiS3/0/0zYE1wa3yIw== +Sec-WebSocket-Version: 13 +Sec-WebSocket-Protocol: binary + + + +...no response..... \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1818 b/results/classifier/accel-gemma3:12b/vmm/1818 new file mode 100644 index 000000000..739992ca1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1818 @@ -0,0 +1,21 @@ + +whpx does not work with hyper-v enabled +Description of problem: +I am experiencing issues with the WHPX (Windows Hypervisor Platform Accelerator) hardware acceleration in QEMU on my Windows 10 22h2 system. When I run QEMU with the `-accel whpx` option, I encounter the following problems: + +2. I receive the error message "WHPX: No accelerator found, hr=00000000" followed by "failed to initialize whpx: No space left on device." +Steps to reproduce: +1. Enable the Hyper-V feature on Windows. +2. Install the latest QEMU version +3. Run the QEMU command with the `-accel whpx` option. +Additional information: +- my cpu : intel i7 6500U +- ram : 8 gigabytes +- gpu : intel hd 520 +- drive : C: -> 200 gigabytes, D: -> 1to (c: 109 used, d: 732 used) +- emulated drive -> 50 gigabytes (500mb used) + + + + +(in french sorry) diff --git a/results/classifier/accel-gemma3:12b/vmm/1818207 b/results/classifier/accel-gemma3:12b/vmm/1818207 new file mode 100644 index 000000000..b79255a22 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1818207 @@ -0,0 +1,32 @@ + +[aarch64] VM status remains "running" after it's suspended + +The issue is observed on aarch64 (I didn't check x86) with latest upstream QEMU bits. + +Steps to reproduce: + +1) start guest + +2) suspend guest with this command: + +# echo mem > /sys/power/state + + Check console messages, which should indicate that guest has been suspended. + +3) check guest status through HMP command "info status": + + (qemu) info status + info status + VM status: running + +Note it's "running", which is incorrect. + +QEMU version: + +# qemu-system-aarch64 --version +QEMU emulator version 3.1.50 (v3.1.0-2203-g9403bcc) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +The issue prevents user from resuming a suspended guest through "system_wakeup" HMP command, because QEMU thinks the guest is in running state and does nothing. + +I think the issues occurs because qemu_system_wakeup_request() doesn't get called. It seems the root cause is with ACPI related code. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1818880 b/results/classifier/accel-gemma3:12b/vmm/1818880 new file mode 100644 index 000000000..e7f01563f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1818880 @@ -0,0 +1,31 @@ + +Deadlock when detaching network interface + +[Impact] +Qemu guests hang indefinitely + +[Description] +When running a Qemu guest with VirtIO network interfaces, detaching an interface that's currently being used can result in a deadlock. The guest instance will hang and become unresponsive to commands, and the only option is to kill -9 the instance. +The reason for this is a dealock between a monitor and an RCU thread, which will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. The monitor thread will acquire the BQL for detaching the network interface, and fire up a helper thread to deal with detaching the network adapter. That new thread needs to wait on the RCU thread to complete the deletion, but the RCU thread wants the BQL to commit its transactions. +This bug is already fixed upstream (73c6e4013b4c rcu: completely disable pthread_atfork callbacks as soon as possible) and included for other series (see below), so we don't need to backport it to Bionic onwards. + +Upstream commit: https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c + +$ git describe --contains 73c6e4013b4c +v2.10.0-rc2~1^2~8 + +$ rmadison qemu +===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ... + qemu | 1:2.11+dfsg-1ubuntu7 | bionic/universe | amd64, ... + qemu | 1:2.12+dfsg-3ubuntu8 | cosmic/universe | amd64, ... + qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe | amd64, ... + +[Test Case] +Being a racing condition, this is a tricky bug to reproduce consistently. We've had reports of users running into this with OpenStack deployments and Windows Server guests, and the scenario is usually like this: +1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface +2) Stress the network interface with e.g. Windows HLK test suite or similar +3) Repeatedly attach/detach the network adapter that's in use +It usually takes more than ~4000 attach/detach cycles to trigger the bug. + +[Regression Potential] +Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with autokpkgtest and scripted Qemu runs. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1818937 b/results/classifier/accel-gemma3:12b/vmm/1818937 new file mode 100644 index 000000000..e98218a00 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1818937 @@ -0,0 +1,38 @@ + +Crash with HV_ERROR on macOS host + +On macOS host running Windows 10 guest, qemu crashed with error message: Error: HV_ERROR. + +Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 4278U. +QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560 +QEMU parameter: qemu-system-x86_64 -m 3000 -drive file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3 + +thread list +Process 56054 stopped + thread #1: tid = 0x2ffec8, 0x00007fff48d0805a vImage`vLookupTable_Planar16 + 970, queue = 'com.apple.main-thread' + thread #2: tid = 0x2ffecc, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #3: tid = 0x2ffecd, 0x00007fff79d715aa libsystem_kernel.dylib`__select + 10 + thread #4: tid = 0x2ffece, 0x00007fff79d71d9a libsystem_kernel.dylib`__sigwait + 10 +* thread #6: tid = 0x2ffed0, 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT + thread #7: tid = 0x2ffed1, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #8: tid = 0x2ffed2, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #11: tid = 0x2fff34, 0x00007fff79d6a17a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread' + thread #30: tid = 0x300c04, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #31: tid = 0x300c16, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #32: tid = 0x300c17, 0x0000000000000000 + thread #33: tid = 0x300c93, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + + +Crashed thread: + +* thread #6, stop reason = signal SIGABRT + * frame #0: 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285 + frame #2: 0x00007fff79cd91c9 libsystem_c.dylib`abort + 127 + frame #3: 0x000000010baa476d qemu-system-x86_64`assert_hvf_ok(ret=<unavailable>) at hvf.c:106 [opt] + frame #4: 0x000000010baa4c8f qemu-system-x86_64`hvf_vcpu_exec(cpu=0x00007f8e5283de00) at hvf.c:681 [opt] + frame #5: 0x000000010b988423 qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x00007f8e5283de00) at cpus.c:1636 [opt] + frame #6: 0x000000010bd9dfce qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:502 [opt] + frame #7: 0x00007fff79e24305 libsystem_pthread.dylib`_pthread_body + 126 + frame #8: 0x00007fff79e2726f libsystem_pthread.dylib`_pthread_start + 70 + frame #9: 0x00007fff79e23415 libsystem_pthread.dylib`thread_start + 13 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1821131 b/results/classifier/accel-gemma3:12b/vmm/1821131 new file mode 100644 index 000000000..40369393b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1821131 @@ -0,0 +1,29 @@ + +VM running under latest Qemu receives 2, 3, 8, and = when sent the keysyms for @, #, *, and + respectively + +Git commit hash where bug was reproduced: 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2 + +A user of my application bVNC reported that when he connects to his VMs running under Qemu, he cannot send @, #, and *. Instead, 2, 3, and 8 appear in the VM respectively. I built the latest Qemu from source, and reproduced the issue. + +bVNC converts keycodes or unicode characters that the Android keyboard sends it to corresponding keysyms. For example, it sends keysym 64 for @ rather than sending SHIFT+2. + +A debug log of the application sending the keysyms shows metaState == 0, indicating lack of modifier keys. + +When 2 appears in place of @: + +03-21 00:11:21.761 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 64. keysym:64, metaState: 0 +03-21 00:11:21.763 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 64. keysym:64, metaState: 0 + +When 3 appears in place of #: + +03-21 00:11:08.947 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 35. keysym:35, metaState: 0 +03-21 00:11:08.950 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 35. keysym:35, metaState: 0 + +When 0 appears instead of *: + +03-21 00:11:28.586 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 42. keysym:42, metaState: 0 +03-21 00:11:28.588 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 42. keysym:42, metaState: 0 + +When = appears instead of +: +03-21 01:05:40.021 10061 10061 I RemoteKeyboard: Sending key. Down: true, key: 43. keysym:43, metaState: 0 +03-21 01:05:40.022 10061 10061 I RemoteKeyboard: Sending key. Down: false, key: 43. keysym:43, metaState: 0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1821595 b/results/classifier/accel-gemma3:12b/vmm/1821595 new file mode 100644 index 000000000..7cef52b9b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1821595 @@ -0,0 +1,18 @@ + +Failed to emulate MMIO access with EmulatorReturnStatus: 2 + +I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: +qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor + + +configuration directives: + +../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\ + --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\ + --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\ + --disable-werror --disable-stack-protector --prefix="../../QEMU-bin" + + +Qemu command line: +qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1821884 b/results/classifier/accel-gemma3:12b/vmm/1821884 new file mode 100644 index 000000000..28e1588a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1821884 @@ -0,0 +1,6 @@ + +Extend uefi-test-tools to report SMBIOS location + +UEFI helper app exposes the pointer to RSDP ACPI table that firmware allocates in guest's RAM +but it doesn't do so for SMBIOS tables. Hence bios table test would skip testing SMBIOS tables +to workaround shortcoming. This bug is a request to expose two new entry point fields (one for SMBIOS 2 and another for SMBIOS 3) so test could check SMBIOS tables when guest is started a with UEFI firmware. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1822798 b/results/classifier/accel-gemma3:12b/vmm/1822798 new file mode 100644 index 000000000..caa2938b1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1822798 @@ -0,0 +1,4 @@ + +The hover of " Full list of releases " is not effective even not visible. + +The hover effect of "Full list of releases " on QEMU website that is https://www.qemu.org/ is not visible and hence effective so made it the issue on git hub and even committed it. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1823458 b/results/classifier/accel-gemma3:12b/vmm/1823458 new file mode 100644 index 000000000..4fd9cb7ee --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1823458 @@ -0,0 +1,42 @@ + +race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu + +[impact] + +on shutdown of a guest, there is a race condition that results in qemu crashing instead of normally shutting down. The bt looks similar to this (depending on the specific version of qemu, of course; this is taken from 2.5 version of qemu): + +(gdb) bt +#0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 +#1 0x00005636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at /build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73 +#2 0x00005636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at /build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205 +#3 0x00005636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, dev=0x5636c1bf6b70) + at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195 +#4 0x00005636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, ring=0x7ffe65c087e0) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364 +#5 0x00005636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895 +#6 0x00005636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, vdev=vdev@entry=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262 +#7 0x00005636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, dev=dev@entry=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293 +#8 0x00005636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, ncs=0x5636c209d110, total_queues=total_queues@entry=1) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371 +#9 0x00005636c08d7745 in virtio_net_vhost_status (status=7 '\a', n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150 +#10 virtio_net_set_status (vdev=<optimized out>, status=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162 +#11 0x00005636c08ec42c in virtio_set_status (vdev=0x5636c2853338, val=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624 +#12 0x00005636c098fed2 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605 +#13 0x00005636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724 +#14 vm_stop (state=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407 +#15 0x00005636c085d240 in main_loop_should_exit () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883 +#16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931 +#17 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683 + + +[test case] + +unfortunately since this is a race condition, it's very hard to arbitrarily reproduce; it depends very much on the overall configuration of the guest as well as how exactly it's shut down - specifically, its vhost user net must be closed from the host side at a specific time during qemu shutdown. + +I have someone with such a setup who has reported to me their setup is able to reproduce this reliably, but the config is too complex for me to reproduce so I have relied on their reproduction and testing to debug and craft the patch for this. + +[regression potential] + +the change adds flags to prevent repeated calls to both vhost_net_stop() and vhost_net_cleanup() (really, prevents repeated calls to vhost_dev_cleanup()). Any regression would be seen when stopping and/or cleaning up a vhost net. Regressions might include failure to hot-remove a vhost net from a guest, or failure to cleanup (i.e. mem leak), or crashes during cleanup or stopping a vhost net. + +[other info] + +this was originally seen in the 2.5 version of qemu - specifically, the UCA version in trusty-mitaka (which uses the xenial qemu codebase). However, this appears to still apply upstream, and I am sending a patch to the qemu list to patch upstream as well. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1823831 b/results/classifier/accel-gemma3:12b/vmm/1823831 new file mode 100644 index 000000000..ef2ba3b03 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1823831 @@ -0,0 +1,13 @@ + +BSD bootloader halts with hypervisor.framework + +Guest: FreeBSD 12.0 Install CD +Host: MacOS 11.14.3 qemu master at 90fb864a7df0a9af677352e94f8225f7b03de922 + +Command arguments: + +qemu-system-x86_64 -m 4000m -cdrom Downloads/FreeBSD-12.0-RELEASE-amd64-bootonly.iso + +When qemu was run with -accel hvf, the bootloader would halt after showing the menu. The bootloader would not respond to any keyboard events. + +Without acceleration option, the bootloader would count down to zero and proceed. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1824704 b/results/classifier/accel-gemma3:12b/vmm/1824704 new file mode 100644 index 000000000..1428e91e8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1824704 @@ -0,0 +1,24 @@ + +-k tr not working after v20171217! turkish keyboard dont working + +hi qemu + +-k tr not working after v20171217! turkish keyboard dont working + +last working without proplem at v20171217! + + +after this version tr keyboard prople. +freedos , winpe , linux images all dont working tr turkish keyboard. + +example press key " ç " show " , " +example 2 press key " . " show " ç " + +tr keyboard work always "en-us" kbd. +:(((((((( + + + +please fix this critical bug. + +Sincerely \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1824768 b/results/classifier/accel-gemma3:12b/vmm/1824768 new file mode 100644 index 000000000..e4129af28 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1824768 @@ -0,0 +1,29 @@ + +Qemu ARMv7 TCG MultiThreading for i386 guest doesn't work + +Using any Linux image (in this case Alpine Linux iso) and want to use all cores of my Raspberry with --accel,thread=multi. I know there is a probably still problem with memory ordering of the host but I have also seen some very old commits which could potentially help with it. + +But anyway, with version qemu-i386 version 3.1.0 (Debian 1:3.1+dfsg-7) +I can see OpenRC starting up services and then the kernel crash. + +With version QEMU emulator version 3.1.93 (v4.0.0-rc3-dirty) +The whole machine crash with this error: +Illegal instruction + + +Using command: +./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi + +Full Console Output: +qemu-system-i386: warning: Guest expects a stronger memory ordering than the host provides +This may cause strange/hard to debug errors +Illegal instruction + + +Kernel: +Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux + +CPU: +ARMv7 Processor rev 5 (v7l) +Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +4 cores \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1825 b/results/classifier/accel-gemma3:12b/vmm/1825 new file mode 100644 index 000000000..cee75e129 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1825 @@ -0,0 +1,15 @@ + +pigz crashes when running in an aarch64 chroot (entered through qemu-binfmt) with qemu 8.1.0-rc*, qemu 8.0.3 is ok +Description of problem: +If qemu 8.1.0-rc1, -rc2 or -rc3 is used, pigz crashes. +``` +# chroot /chroot/aarch64 pigz /tmp/test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +``` +With qemu 8.0.3 on the same chroot enviroment, it works and produces the expected /chroot/aarch64/tmp/test.gz +Steps to reproduce: +1. Install an aarch64 chroot environment on x86_64 +2. Try using pigz to compress a file inside the chroot environment using qemu-binfmt +Additional information: +Unfortunately `git bisect`-ing the issue isn't easy because many snapshots between 8.0.0 (good) and 8.1.0-rc1 (first known bad) don't compile. diff --git a/results/classifier/accel-gemma3:12b/vmm/1825207 b/results/classifier/accel-gemma3:12b/vmm/1825207 new file mode 100644 index 000000000..2e54b96c2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1825207 @@ -0,0 +1,26 @@ + +fw_cfg_machine_reset destroys user bootorder setting + +Demonstrated against 2.11 (ubuntu bionic 1:2.11+dfsg-1ubuntu7.12) and 3.1 (as built under bionic from the 1:3.1+dfsg-2ubuntu3 source package) although the code hasn't changed between them and github master also appears to have this same code branch. + +What I was trying to do: select a boot disk using `-fw_cfg name=bootorder,string=/pci@i0cf8/*@6` based on the qemu and seabios documentation. (Why do I want to do that? using qemu for installer testing for a specific kind of real machine and need to match the bios boot order.) + +What happened instead: same search-based boot order that I get without that option. Also, /sys/firmware/qemu_fw_cfg/by_name/bootorder/raw is empty and .../size is "0". + +Brutal work around that did a useful thing: + +--- qemu-3.1+dfsg.orig/hw/nvram/fw_cfg.c ++++ qemu-3.1+dfsg/hw/nvram/fw_cfg.c +@@ -869,8 +869,10 @@ static void fw_cfg_machine_reset(void *o + FWCfgState *s = opaque; + char *bootindex = get_boot_devices_list(&len); + ++#if 0 + ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len); + g_free(ptr); ++#endif + } + +This change allowed the boot to work (so my bootorder setting was making it to seabios) and also showed up explicitly in /sys/firmware/qemu_fw_cfg. + +I don't know if fw_cfg_modify_file is intended to append rather than replace, but it doesn't; based on the seabios "Runtime_config" docs which suggest "look at the Searching bootorder for output and paste that into the bootorder file" I'd instead just have it only fill in bootorder if there's *no* existing setting, since a user can read out the defaults and copy them in as described if they want the fallback, but that's just from my interpretation of the docs. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1826200 b/results/classifier/accel-gemma3:12b/vmm/1826200 new file mode 100644 index 000000000..3473b664c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1826200 @@ -0,0 +1,20 @@ + +RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files + +The feature added in + + https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd + +and exposed by libvirt as + + https://libvirt.org/formatdomain.html#elementsSysinfo + +allows the user to specify up to 255 strings in the unofmatted area of the Type 11 SMBIOS table, where each string may be of arbitrary length. This feature is useful for exposing arbitrary text to arbitrary guest components (in particular when strings are prefixed with "application identifiers"). + +Right now, strings can only be specified on the QEMU command line, which limits the amount of data that can be passed. Please enable users to pass data from regular files too. + +For example: + + $QEMU -smbios type=11,value=Hello,txtfile=file1.txt,txtfile=file2.txt + +where "file1.txt" and "file2.txt" could be text files containing ASCII application prefixes, followed by base64-encoded binary data. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1826599 b/results/classifier/accel-gemma3:12b/vmm/1826599 new file mode 100644 index 000000000..4e7f8b3ac --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1826599 @@ -0,0 +1,19 @@ + +qemu crashes with HV_ERROR with any guest when using HVF on macos + +qemu reliably crashes (after some unknown amount of time) for any guest I've run on macos with HVF acceleration. + +I'm currently running Haiku. After booting and running normally for a few minutes, it abruptly crashes and shows this error on stdout (I'm including the command line arguments): + ++ ISO=haiku-release-anyboot.iso ++ ACCEL='-accel hvf -machine type=q35,accel=hvf' ++ MEM='-m 1G' ++ SMP='-c 2' ++ NET='-device virtio-net,netdev=vmnic -netdev user,id=vmnic' ++ IMG_CD='-cdrom haiku-release-anyboot.iso' ++ IMG_HDD='-device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0' ++ DISPLAY='-usb -device usb-tablet' ++ qemu-system-x86_64 -accel hvf -machine type=q35,accel=hvf -usb -device usb-tablet -m 1G -device virtio-net,netdev=vmnic -netdev user,id=vmnic -device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: Error: HV_ERROR +./qemu-boot.sh: line 19: 67497 Abort trap: 6 qemu-system-x86_64 $ACCEL $CPU $EFI $DISPLAY $MEM $NET $IMG_HDD \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1827005 b/results/classifier/accel-gemma3:12b/vmm/1827005 new file mode 100644 index 000000000..accd3a2a0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1827005 @@ -0,0 +1,14 @@ + +hvf: ubuntu iso boot menu issue + +With hvf acceleration on macOS, ubuntu server installation ISO boot language menu shows fractured images. + +To reproduce the issue: +./x86_64-softmmu/qemu-system-x86_64 -m 800 -accel hvf -cdrom ~/ubuntu-16.04.4-server-amd64.iso + +Control: +./x86_64-softmmu/qemu-system-x86_64 -m 800 -accel tcg -cdrom ~/ubuntu-16.04.4-server-amd64.iso + +Host: macOS Mojave 10.14.3 +Guest: Ubuntu Server 16.04.4 ISO +QEMU: version 3.1.94 (v4.0.0-rc4) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1828 b/results/classifier/accel-gemma3:12b/vmm/1828 new file mode 100644 index 000000000..4a394b5f6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1828 @@ -0,0 +1,22 @@ + +[v8.0.4 regression] `qemu-system-x86_64: -accel hvf: Unknown Error` +Description of problem: +`-accel hvf` crashes with "Unknown Error". +Regression in v8.0.4. + +The master branch doesn't seem affected. +Steps to reproduce: +v8.0.3: +```console +$ qemu-system-x86_64 -accel hvf +(shows iPXE screen, as expected) +``` + +v8.0.4: +```console +$ qemu-system-x86_64 -accel hvf +qemu-system-x86_64: -accel hvf: Unknown Error +Abort trap: 6 +``` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1828207 b/results/classifier/accel-gemma3:12b/vmm/1828207 new file mode 100644 index 000000000..131d5bdf2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1828207 @@ -0,0 +1,7 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server + +In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on. +Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability. + +Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1828272 b/results/classifier/accel-gemma3:12b/vmm/1828272 new file mode 100644 index 000000000..935b5a47b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1828272 @@ -0,0 +1,22 @@ + +4.0 breaks keyboard autorepeat in guests with xserver + +Description: +In a linux/bsd guest within X, pressing and holding a key for a short time causes an endless repeat of that key in the guest. The release of the key gets ignored. +Example 1: pressing and holding 'a' for a few seconds results in typing of 'aaaaaaaaaaaa...' endlessly. +Example 2: pressing and holding 'Backspace' for a few seconds results in deleting all your previously typed text. + +It doesn't happen within a VT in the guest. It also doesn't happen with guests that run windows, reactos or haiku for example. + +The problem goes away, when disabling xorgs autorepeat function via "xset -r" in the host. +Normally, this setting should not have any effect on the guest, since it has it's own autorepeat setting. So there is some conflict here. + +Steps to reproduce: +Start any linux/bsd guest system with xserver, open a terminal, press and hold a key for a short time: Look how it gets typed endlessly (Try a few times if it doesn't happen immediately). +The easiest way is to run a linux live cd, like this (Link to example iso :http://download.grml.org/grml64-full_2018.12.iso) +$ qemu-system-x86_64 -enable-kvm -m 512 -boot d -cdrom grml64-full_2018.12.iso + + +Qemu version info: +QEMU emulator version 4.0.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1828507 b/results/classifier/accel-gemma3:12b/vmm/1828507 new file mode 100644 index 000000000..72a3f3d84 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1828507 @@ -0,0 +1,42 @@ + +qemu-system-ppc64 smp crash on manual reset + +Host Environment: + x86_64 Linux v5.0.2 + QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4) + SLOF: + Build Date = Jan 14 2019 18:00:39 + FW Version = git-a5b428e1c1eae703 + +Problem: Qemu crash immediately after a manual reset + (this is not the initial reset which launches the guest). + +Steps: + +1. Download Debian ppc64el mini.iso: + http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso +2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a single CPU, I was unable + to reproduce the crash. + qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso +3. SLOF prints the version info on the serial device, and proceeds to boot. +4. After a few seconds, the GRUB menu appears on the VGA screen. +5. Select one of the install options (I have tested with Default and Expert), and wait + for the Debian's text-mode installer (blue-gray-red) screen to appear. +6. Click Machine->Reset (or enter system_reset on the qemu monitor). +7. Notice that, on the serial device, SLOF has printed the version info. That is, the system + has reset and is attempting to boot again. +8. On the host cmd prompt, qemu dies after printing this fatal error and spewing the + contents of the CPU registers: + + qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support + <CPU contents> (See attached out.txt for details) + Aborted (core dumped) + + +The HV exception is either + (a) 70 = HISI, which occurs when NIP contains an outright bogus or inaccessible value, or + (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner value, and + the cpu attempts to run the instruction at that address. + +The exception can occur on either of the CPUs. It occurs when qemu is running the SLOF +code. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1828508 b/results/classifier/accel-gemma3:12b/vmm/1828508 new file mode 100644 index 000000000..309864c62 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1828508 @@ -0,0 +1,25 @@ + +qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" + +Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a Windows 10 machine. + +Converting a VHD to VMDK. +qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk" + +I have also tried: +qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk" + +Attaching the VMDK to a VM in VMware produces the following error when powering on. + +Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. +Target: MyVM1 +vCenter Server: VCENTER +Error Stack +An error was received from the ESX host while powering on VM MyVM1. +Failed to start the virtual machine. +Module DevicePowerOn power on failed. +Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' +Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. + + +If I do not specify the adapter type, it creates an IDE VMDK which works perfectly. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1828608 b/results/classifier/accel-gemma3:12b/vmm/1828608 new file mode 100644 index 000000000..7ab30bd4b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1828608 @@ -0,0 +1,8 @@ + +Chardev websocket might not support pasting more than a few chars + +When sending more than 4-5 characters on the websocket serial console (with pasting for example), the guest might not receive all of them, or worse interpret the input as Magic SysRq keys. + +This might be due to the io loop not checking the backend readiness before calling the read function. + +Attached patched fixes the problem on my system. I'm not sure it's the proper approach, this is just to start discussion. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1829 b/results/classifier/accel-gemma3:12b/vmm/1829 new file mode 100644 index 000000000..c4ad59f2b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1829 @@ -0,0 +1,89 @@ + +DoS via assert failure by guest user +Description of problem: +As root in guest VM user can execute special script, which crashes the whole VM with error + +```plaintext +hw/display/qxl.c:1594 inside of function void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0` failed +``` +Steps to reproduce: +1. This bug can be reproduced with: + + ```bash + cat << EOF | ./build/qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio + outl 0xcf8 0x8000101c + outl 0xcfc 0xc000 + outl 0xcf8 0x80001001 + outl 0xcfc 0x01000000 + outl 0xc006 0x00 + EOF + ``` +2. Also, we can execute this python3 script inside guest VM as root (to invoke VM use command: **_qemu-system-x86_64 -vga qxl -hda debian.img -m 2048 -nodefaults_**): + + ```python + import os + f = os.open("/dev/port", os.O_RDWR|os.O_NDELAY) + l = os.lseek(f, 0xcf8, 0) + os.write(f, b'\x80\x00\x10\x1c') + l = os.lseek(f, 0xcfc, 0) + os.write(f, b'\xc0\x00') + l = os.lseek(f, 0xcf8, 0) + os.write(f, b'\x80\x00\x10\x01') + l = os.lseek(f, 0xcfc, 0) + os.write(f, b'\x01\x00\x00\x00') + l = os.lseek(f, 0xc006, 0) + os.write(f, b'\x00') + ``` + + This script causes VM to crash. + + [PoC_qxl-vga_crash.mkv](/uploads/7ee262c20dca69aa9417812f6a93a532/PoC_qxl-vga_crash.mkv) +Additional information: +This issue was found by fuzzing. Here is an auto-generated C source code for a test case that will reproduce the bug. + +```plaintext +/* + * Autogenerated Fuzzer Test Case + * + * Copyright (c) 2023 Artem Nasonov <anasonov@astralinux.ru> + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqtest.h" + +/* + * cat << EOF | qemu-system-x86_64 -vga qxl -hda \ + * ~/Downloads/virtualdebian.img -m 2048 -nodefaults -qtest stdio + * outl 0xcf8 0x8000101c + * outl 0xcfc 0xc000 + * outl 0xcf8 0x80001001 + * outl 0xcfc 0x01000000 + * outl 0xc006 0x00 + * EOF +*/ +static void test_qxl_set_mode(void) +{ +QTestState *s = qtest_init("-vga qxl -m 2048 -nodefaults"); +qtest_outl(s, 0xcf8, 0x8000101c); +qtest_outl(s, 0xcfc, 0xc000); +qtest_outl(s, 0xcf8, 0x80001001); +qtest_outl(s, 0xcfc, 0x01000000); +qtest_outl(s, 0xc006, 0x00); +qtest_quit(s); +}int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "x86_64") == 0) { + qtest_add_func("fuzz/test_qxl_set_mode",test_qxl_set_mode); + } + + return g_test_run(); +} +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1829242 b/results/classifier/accel-gemma3:12b/vmm/1829242 new file mode 100644 index 000000000..5bdbabb0e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1829242 @@ -0,0 +1,12 @@ + +qemu on windows host exits after savevm command + +I'm running qemu-system-i386.exe 3.1.0 with this command line: +"C:\Program Files\qemu\qemu-system-i386.exe" -L C:\user\qemu\pc-bios\ -name win7 -m 4G -uuid 564db62e-e031-b5cf-5f34-a75f8cefa98e -rtc base=localtime -accel hax -hdd C:\VirtualMachines\Dev\Win10x64_VS17\swap.qcow "C:\VirtualMachines\qemu\qemu_win7.qcow" +Host OS Windows 10 x64, guest OS Wondows 7 x86. + +Wait till the OS loads, go to compat_monitor0 tab and enter command: +savevm loaded_win +After a few seconds qemu exits, running it another time and entering command: +info snapshots +says "There is no snapshot available". I've tried rinning it with -accel tcg, with same results. I've tried less memory (1G), same results. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1829964 b/results/classifier/accel-gemma3:12b/vmm/1829964 new file mode 100644 index 000000000..ea73f60f3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1829964 @@ -0,0 +1,34 @@ + +HOST VRAM Leak when performs android-x86 window rotation with Virt-GPU + +I will report something strange thing about host VRAM leakage after anroid-x86 window rotation when it runs with virt-gpu(+ virgl-renderer) + +Please watching below video link. + +https://www.youtube.com/watch?v=mJIbGZLWF1s&feature=youtu.be + +(orginal video file : https://drive.google.com/file/d/1lkdTx_8yTbSVjKXlnxnnk96fWe-w6Mxb/view?usp=sharing) + +I don't sure what is the problem... + +Here are my tested history +-------------------------------------------------------------------------------------------------- +Install android-x86 on I7 desktop PCs with intel UHD GPU - No leak. +Install android-x86 on I7 desktop PCs with NVIDIA GTX GPU series - No leak. +Install android-x86 on guest machine emulated skylake cpu with QEMU(+virt-gpu, virgl-renderer) - Leak +(HOST CPU - I5, INTEL UHD GPU) +Install android-x86 on guest machine emulated skylake cpu with QEMU(+virt-gpu, virgl-renderer) - Leak +(HOST CPU - I7, NVIDIA GTX GPU) + +COMMON: +In case of NVIDIA GPU : check vram using nvidia-smi +In case of intel UHD GPU : check shared-vram using free cmd + +We checked guest android-x86 system down when vram is full after performing many rotation +------------------------------------------------------------------------------------------- + +Is it virt-gpu driver's problem? + +I hope someone can help me... + +Thanks in advance!! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1831354 b/results/classifier/accel-gemma3:12b/vmm/1831354 new file mode 100644 index 000000000..7a2133a62 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1831354 @@ -0,0 +1,9 @@ + +unable to read symlinks when mounting 9p filesystem with security_model=mapped + +I am trying to use clang that is mounted from a 9p filesystem that has the options + -fsdev local,id=virtfs3,path=/clang,security_model=mapped-file -device virtio-9p-pci,fsdev=virtfs3,mount_tag=clang + +clang has symlinks to clang-9. eg /clang/clang/bin/clang is a symlink that points to clang-9 in the current directory. + +the clang filesystem is on a bind mount point on /clang/clang on the host and this is mapped to the same place on the guest. If I have the same virtfs mount point with the security_model=none I don't have this problem. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1831362 b/results/classifier/accel-gemma3:12b/vmm/1831362 new file mode 100644 index 000000000..272dc45d1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1831362 @@ -0,0 +1,28 @@ + +European keyboard PC-105 deadkey + +With a freshly compiled version of qemu 4.0.50 on Windows 10 (host) + +I am using 3 different Belgian keyboards and I have the same behaviour +- 2 USB keyboards (Logitech and HP) and +- the keyboard of my laptop (HP) + +3 characters on the same key cannot be used (the key seams to be dead): +< (less than), +> (greater than) used with the combination of LShift or RShift +\ (backslash) used with the combination of AltGr + +Using grub command mode from an archlinux installation (5.1.4) +The keyboard seams to be a mix of azerty and qwerty keyboard +all letters are correctly mapped but all numbers and special +characters are not + +Using sendkey in monitor +"sendkey <" results in : \ +"sendkey shift-<" results in : | +"sendkey ctrl-alt-<" results in : nothing + +REM: VirtualBox can handle this key and with the showkey command + from the archlinux kbd package, it shows : + keycode 86 press + keycode 86 release \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1831486 b/results/classifier/accel-gemma3:12b/vmm/1831486 new file mode 100644 index 000000000..1b7bd04c5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1831486 @@ -0,0 +1,38 @@ + +qmp monitor deadlock (with spice events for ex) + +If an event is emitted during monitor_flush_locked() it will deadlock. + +Thread 1 (Thread 0x7f14f1854000 (LWP 7245)): +#0 0x00007f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0 +#1 0x00007f14fc2fedc9 in pthread_mutex_lock () at /lib64/libpthread.so.0 +#2 0x000055de60e19327 in qemu_mutex_lock_impl (mutex=0x55de61859e58, file=0x55de60f1a640 "/home/elmarco/src/qq/monitor.c", line=438) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66 +#3 0x000055de6085c5af in monitor_puts (mon=0x55de61859d30, str=0x55de62a61d30 "{\"timestamp\": {\"seconds\": 1559585795, \"microseconds\": 508720}, \"event\": \"SPICE_DISCONNECTED\", \"data\": {\"server\": {\"port\": \"/tmp/.9IW52Z/spice.sock\", \"family\": \"unix\", \"host\": \"localhost\"}, \"client\": {"...) at /home/elmarco/src/qq/monitor.c:438 +#4 0x000055de6085c85a in qmp_send_response (mon=0x55de61859d30, rsp=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:493 +#5 0x000055de6085c8ee in monitor_qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:521 +#6 0x000055de6085c9ea in monitor_qapi_event_queue_no_reenter (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:546 +#7 0x000055de6085cd7a in qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:621 +#8 0x000055de60e04bc3 in qapi_event_send_spice_disconnected (server=0x55de61ee7b30, client=0x55de620c9090) at qapi/qapi-events-ui.c:101 +#9 0x000055de60c84381 in channel_event (event=3, info=0x55de6222f4c0) at /home/elmarco/src/qq/ui/spice-core.c:234 +#10 0x00007f14fc70ba3b in reds_handle_channel_event (reds=<optimized out>, event=3, info=0x55de6222f4c0) at reds.c:318 +#11 0x00007f14fc6f407b in main_dispatcher_self_handle_channel_event (info=0x55de6222f4c0, event=3, self=0x55de61a5b0b0) at main-dispatcher.c:191 +#12 0x00007f14fc6f407b in main_dispatcher_channel_event (self=0x55de61a5b0b0, event=event@entry=3, info=0x55de6222f4c0) at main-dispatcher.c:191 +#13 0x00007f14fc713cf3 in red_stream_push_channel_event (s=s@entry=0x55de6222f400, event=event@entry=3) at red-stream.c:416 +#14 0x00007f14fc713d2b in red_stream_free (s=0x55de6222f400) at red-stream.c:390 +#15 0x00007f14fc6fa67c in red_channel_client_finalize (object=0x55de62511360) at red-channel-client.c:347 +#16 0x00007f14fe4cfcf0 in g_object_unref () at /lib64/libgobject-2.0.so.0 +#17 0x00007f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at red-channel-client.c:1340 +#18 0x00007f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at red-channel-client.c:1303 +#19 0x00007f14fc6cd479 in red_char_device_send_msg_to_client (client=<optimized out>, msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307 +#20 0x00007f14fc6cd479 in red_char_device_send_msg_to_clients (msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307 +#21 0x00007f14fc6cd479 in red_char_device_read_from_device (dev=0x55de61a5b3b0) at char-device.c:355 +#22 0x000055de60a27dba in spice_chr_write (chr=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at /home/elmarco/src/qq/chardev/spice.c:201 +#23 0x000055de60d89e29 in qemu_chr_write_buffer (s=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, offset=0x7ffcd5e1a860, write_all=false) at /home/elmarco/src/qq/chardev/char.c:113 +#24 0x000055de60d89f96 in qemu_chr_write (s=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, write_all=false) at /home/elmarco/src/qq/chardev/char.c:148 +#25 0x000055de60d8cf78 in qemu_chr_fe_write (be=0x55de61859d30, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at /home/elmarco/src/qq/chardev/char-fe.c:42 +#26 0x000055de6085c40f in monitor_flush_locked (mon=0x55de61859d30) at /home/elmarco/src/qq/monitor.c:404 +#27 0x000055de6085c614 in monitor_puts (mon=0x55de61859d30, str=0x55de622f6a40 "{\"return\": {}, \"id\": 2}\n") at /home/elmarco/src/qq/monitor.c:446 +#28 0x000055de6085c85a in qmp_send_response (mon=0x55de61859d30, rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:493 +#29 0x000055de60865902 in monitor_qmp_respond (mon=0x55de61859d30, rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:4128 +#30 0x000055de60865a19 in monitor_qmp_dispatch (mon=0x55de61859d30, req=0x55de622ec000) at /home/elmarco/src/qq/monitor.c:4157 +#31 0x000055de60865ce2 in monitor_qmp_bh_dispatcher (data=0x0) at /home/elmarco/src/qq/monitor.c:4224 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1831750 b/results/classifier/accel-gemma3:12b/vmm/1831750 new file mode 100644 index 000000000..c820a0744 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1831750 @@ -0,0 +1,71 @@ + +virtual machine cpu soft lockup when qemu attach disk + +Hi, I found a problem that virtual machine cpu soft lockup when I attach a disk to the vm in the case that + +backend storage network has a large delay or IO pressure is too large. + +1) The disk xml which I attached is: + + <disk type='block' device='lun' rawio='yes'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/mapper/360022a11000c1e0a0787c23a000001cb'/> + <backingStore/> + <target dev='sdb' bus='scsi'/> + <alias name='scsi0-0-1-0'/> + <address type='drive' controller='0' bus='0' target='1' unit='0'/> + </disk> + +2) The bt of qemu main thread: + +#0 0x0000ffff9d78402c in pread64 () from /lib64/libpthread.so.0 +#1 0x0000aaaace3357d8 in pread64 (__offset=0, __nbytes=4096, __buf=0xaaaad47a5200, __fd=202) at /usr/include/bits/unistd.h:99 +#2 raw_is_io_aligned (fd=fd@entry=202, buf=buf@entry=0xaaaad47a5200, len=len@entry=4096) at block/raw_posix.c:294 +#3 0x0000aaaace33597c in raw_probe_alignment (bs=bs@entry=0xaaaad32ea920, fd=202, errp=errp@entry=0xfffffef7a330) at block/raw_posix.c:349 +#4 0x0000aaaace335a48 in raw_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330) at block/raw_posix.c:811 +#5 0x0000aaaace3404b0 in bdrv_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330, errp@entry=0xfffffef7a360) at block/io.c:122 +#6 0x0000aaaace340504 in bdrv_refresh_limits (bs=bs@entry=0xaaaad09ce800, errp=errp@entry=0xfffffef7a3b0) at block/io.c:97 +#7 0x0000aaaace2eb9f0 in bdrv_open_common (bs=bs@entry=0xaaaad09ce800, file=file@entry=0xaaaad0e89800, options=<optimized out>, errp=errp@entry=0xfffffef7a450) +at block.c:1194 +#8 0x0000aaaace2eedec in bdrv_open_inherit (filename=<optimized out>, filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", +reference=reference@entry=0x0, options=<optimized out>, options@entry=0xaaaad3d0f4b0, flags=<optimized out>, flags@entry=128, parent=parent@entry=0x0, +child_role=child_role@entry=0x0, errp=errp@entry=0xfffffef7a710) at block.c:1895 +#9 0x0000aaaace2ef510 in bdrv_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0, +options=options@entry=0xaaaad3d0f4b0, flags=flags@entry=128, errp=errp@entry=0xfffffef7a710) at block.c:1979 +#10 0x0000aaaace331ef0 in blk_new_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0, +options=options@entry=0xaaaad3d0f4b0, flags=128, errp=errp@entry=0xfffffef7a710) at block/block_backend.c:213 +#11 0x0000aaaace0da1f4 in blockdev_init (file=file@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", bs_opts=bs_opts@entry=0xaaaad3d0f4b0, +errp=errp@entry=0xfffffef7a710) at blockdev.c:603 +#12 0x0000aaaace0dc478 in drive_new (all_opts=all_opts@entry=0xaaaad4dc31d0, block_default_type=<optimized out>) at blockdev.c:1116 +#13 0x0000aaaace0e3ee0 in add_init_drive ( +optstr=optstr@entry=0xaaaad0872ec0 "file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native") +at device_hotplug.c:46 +#14 0x0000aaaace0e3f78 in hmp_drive_add (mon=0xfffffef7a810, qdict=0xaaaad0c8f000) at device_hotplug.c:67 +#15 0x0000aaaacdf7d688 in handle_hmp_command (mon=0xfffffef7a810, cmdline=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3199 +#16 0x0000aaaacdf7d778 in qmp_human_monitor_command ( +command_line=0xaaaacfc8e3c0 "drive_add dummy file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native", +has_cpu_index=false, cpu_index=0, errp=errp@entry=0xfffffef7a968) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:660 +#17 0x0000aaaace0fdb30 in qmp_marshal_human_monitor_command (args=<optimized out>, ret=0xfffffef7a9e0, errp=0xfffffef7a9d8) at qmp-marshal.c:2223 +#18 0x0000aaaace3b6ad0 in do_qmp_dispatch (request=<optimized out>, errp=0xfffffef7aa20, errp@entry=0xfffffef7aa40) at qapi/qmp_dispatch.c:115 +#19 0x0000aaaace3b6d58 in qmp_dispatch (request=<optimized out>) at qapi/qmp_dispatch.c:142 +#20 0x0000aaaacdf79398 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4010 +#21 0x0000aaaace3bd6c0 in json_message_process_token (lexer=0xaaaacf834c80, input=<optimized out>, type=JSON_RCURLY, x=214, y=274) at qobject/json_streamer.c:105 +#22 0x0000aaaace3f3d4c in json_lexer_feed_char (lexer=lexer@entry=0xaaaacf834c80, ch=<optimized out>, flush=flush@entry=false) at qobject/json_lexer.c:319 +#23 0x0000aaaace3f3e6c in json_lexer_feed (lexer=0xaaaacf834c80, buffer=<optimized out>, size=<optimized out>) at qobject/json_lexer.c:369 +#24 0x0000aaaacdf77c64 in monitor_qmp_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4040 +#25 0x0000aaaace0eab18 in tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=0xaaaacf90b280) at qemu_char.c:3260 +#26 0x0000ffff9dadf200 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#27 0x0000aaaace3c4a00 in glib_pollfds_poll () at util/main_loop.c:230 +--Type <RET> for more, q to quit, c to continue without paging-- +#28 0x0000aaaace3c4a88 in os_host_main_loop_wait (timeout=<optimized out>) at util/main_loop.c:278 +#29 0x0000aaaace3c4bf0 in main_loop_wait (nonblocking=<optimized out>) at util/main_loop.c:534 +#30 0x0000aaaace0f5d08 in main_loop () at vl.c:2120 +#31 0x0000aaaacdf3a770 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:5017 + + +From the bt we can see, when do qmp sush as drive_add, qemu main thread locks the qemu_global_mutex and do pread in raw_probe_alignmen. Pread is a synchronous operation. If backend storage network has a large delay or IO pressure is too large, the pread operation will not return for a long time, which make vcpu thread can't acquire qemu_global_mutex for a long time and make the vcpu thread unable to be scheduled for a long time. So virtual machine cpu soft lockup happened. + + +I thank qemu main thread should not hold qemu_global_mutex for a long time when do qmp that involving IO synchronous operation sush pread , ioctl, etc. + +Do you have any solutions or good ideas about it? Thanks for your reply! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1833048 b/results/classifier/accel-gemma3:12b/vmm/1833048 new file mode 100644 index 000000000..8d46c3937 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1833048 @@ -0,0 +1,9 @@ + +Guest Agent get-fsinfo doesn't show ZFS volumes + +Calling get-fsinfo on a virtual machine does not include ZFS volumes. Calling on a system with a single ZFS disk (ZFS as root fs) simply returns '[]', if other disks exist on the guest it only shows these. + +Expected behaviour: Show file system details like with other fs formats. + +Tried with debian stretch default qemu-guest-agent package and v4.0.0 from git, compiled locally - result is the same. +Host is using QEMU 3.0.1, but that shouldn't matter, right? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1834 b/results/classifier/accel-gemma3:12b/vmm/1834 new file mode 100644 index 000000000..b0f126f2a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1834 @@ -0,0 +1,185 @@ + +qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed. +Description of problem: + +Steps to reproduce: +1. Run qemu using the provided command line +2. linux kernel boot and qemu crashes at pci bus scan step +3. +Additional information: +``` +SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org +iPXE (http://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+3EFD0CE0+3EF30CE0 CA00 +iPXE (http://ipxe.org) 00:05.0 CB00 PCI2.10 PnP PMM+3EF1FCE0 3EF30CE0 CB00 +Booting from ROM... +[ 0.000000] Linux version 6.1.38-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230620) #1 SMP PREEMPT_DYNAMIC Thu Jul 6 18:52:54 UTC 2023 +[ 0.000000] Command line: console=ttyS0 +[ 0.000000] x86/fpu: x87 FPU will use FXSAVE +[ 0.000000] signal: max sigframe size: 1040 +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000003ffdf000-0x000000003fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 3.0.0 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 0.000000] last_pfn = 0x3ffdf max_arch_pfn = 0x400000000 +[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.000000] found SMP MP-table at [mem 0x000f5b80-0x000f5b8f] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F59A0 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000003FFE238A 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000003FFE217A 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000003FFE0040 00213A (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000003FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000003FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000003FFE22EE 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: MCFG 0x000000003FFE2326 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: WAET 0x000000003FFE2362 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: Reserving FACP table memory at [mem 0x3ffe217a-0x3ffe226d] +[ 0.000000] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe2179] +[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f] +[ 0.000000] ACPI: Reserving APIC table memory at [mem 0x3ffe226e-0x3ffe22ed] +[ 0.000000] ACPI: Reserving HPET table memory at [mem 0x3ffe22ee-0x3ffe2325] +[ 0.000000] ACPI: Reserving MCFG table memory at [mem 0x3ffe2326-0x3ffe2361] +[ 0.000000] ACPI: Reserving WAET table memory at [mem 0x3ffe2362-0x3ffe2389] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000003ffdefff] +[ 0.000000] Normal empty +[ 0.000000] Device empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff] +[ 0.000000] node 0: [mem 0x0000000000100000-0x000000003ffdefff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000003ffdefff] +[ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA: 97 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA32: 33 pages in unavailable ranges +[ 0.000000] ACPI: PM-Timer IO Port: 0x608 +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.000000] ACPI: Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs +[ 0.000000] [mem 0x40000000-0xafffffff] available for PCI devices +[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 +[ 0.000000] percpu: Embedded 52 pages/cpu s173288 r8192 d31512 u1048576 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 257759 +[ 0.000000] Kernel command line: console=ttyS0 +[ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off +[ 0.000000] Memory: 1002116K/1048052K available (12294K kernel code, 1469K rwdata, 2600K rodata, 1488K init, 2040K bss, 45680K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 31276 entries in 123 pages +[ 0.000000] ftrace: allocated 123 pages with 6 groups +[ 0.000000] ftrace: allocating 31276 entries in 123 pages +[ 0.000000] ftrace: allocated 123 pages with 6 groups +[ 0.000000] Dynamic Preempt: none +[ 0.000000] rcu: Preemptible hierarchical RCU implementation. +[ 0.000000] rcu: RCU event tracing is enabled. +[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2. +[ 0.000000] Trampoline variant of Tasks RCU enabled. +[ 0.000000] Rude variant of Tasks RCU enabled. +[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. +[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16 +[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 0.000000] Console: colour VGA+ 80x25 +[ 0.000000] printk: console [ttyS0] enabled +[ 0.000000] ACPI: Core revision 20220331 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.020000] APIC: Switch to symmetric I/O mode setup +[ 0.040000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.120000] tsc: Unable to calibrate against PIT +[ 0.120000] tsc: using HPET reference calibration +[ 0.120000] tsc: Detected 2299.960 MHz processor +[ 0.001362] tsc: Marking TSC unstable due to TSCs unsynchronized +[ 0.002851] Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.92 BogoMIPS (lpj=22999600) +[ 0.004441] pid_max: default: 32768 minimum: 301 +[ 0.019780] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.020332] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[ 0.078474] process: using AMD E400 aware idle routine +[ 0.079221] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.079631] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.081092] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.082698] Spectre V2 : Mitigation: Retpolines +[ 0.083053] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.083616] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT +[ 0.348864] Freeing SMP alternatives memory: 32K +[ 0.514732] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +[ 0.536546] cblist_init_generic: Setting adjustable number of callback queues. +[ 0.537604] cblist_init_generic: Setting shift to 1 and lim to 1. +[ 0.538995] cblist_init_generic: Setting shift to 1 and lim to 1. +[ 0.541338] Performance Events: PMU not available due to virtualization, using software events only. +[ 0.548504] rcu: Hierarchical SRCU implementation. +[ 0.548986] rcu: Max phase no-delay instances is 1000. +[ 0.563842] smp: Bringing up secondary CPUs ... +[ 0.583950] x86: Booting SMP configuration: +[ 0.584395] .... node #0, CPUs: #1 +[ 0.802667] smp: Brought up 1 node, 2 CPUs +[ 0.803300] smpboot: Max logical packages: 1 +[ 0.803821] smpboot: Total of 2 processors activated (9202.49 BogoMIPS) +[ 0.864556] devtmpfs: initialized +[ 0.897545] x86/mm: Memory block size: 128MB +[ 0.936982] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.938878] futex hash table entries: 512 (order: 3, 32768 bytes, linear) +[ 0.980994] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 1.004001] thermal_sys: Registered thermal governor 'step_wise' +[ 1.004143] thermal_sys: Registered thermal governor 'user_space' +[ 1.009528] cpuidle: using governor menu +[ 1.022723] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 1.043717] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 1.050546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 1.060576] PCI: Using configuration type 1 for base access +[ 1.074215] mtrr: your CPUs had inconsistent fixed MTRR settings +[ 1.075157] mtrr: your CPUs had inconsistent variable MTRR settings +[ 1.076043] mtrr: your CPUs had inconsistent MTRRdefType settings +[ 1.076840] mtrr: probably your BIOS does not setup all CPUs. +[ 1.077612] mtrr: corrected configuration. +[ 1.453630] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages +[ 1.454286] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page +[ 1.467152] raid6: skipped pq benchmark and selected sse2x4 +[ 1.467152] raid6: using intx1 recovery algorithm +[ 1.485004] ACPI: Added _OSI(Module Device) +[ 1.485539] ACPI: Added _OSI(Processor Device) +[ 1.485909] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 1.486309] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.578101] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.670966] ACPI: Interpreter enabled +[ 1.676848] ACPI: PM: (supports S0 S3 S5) +[ 1.677404] ACPI: Using IOAPIC for interrupt routing +[ 1.683268] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 1.684107] PCI: Using E820 reservations for host bridge windows +[ 1.691382] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 1.828171] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 1.831923] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] +[ 1.839401] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC] +[ 1.843631] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability] +[ 1.867627] PCI host bridge to bus 0000:00 +[ 1.868866] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 1.870044] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 1.870572] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 1.871151] pci_bus 0000:00: root bus resource [mem 0x40000000-0xafffffff window] +[ 1.871719] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 1.872269] pci_bus 0000:00: root bus resource [mem 0x100000000-0x8ffffffff window] +[ 1.873668] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 1.880983] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 1.898659] pci 0000:00:01.0: [1234:1111] type 00 class 0x030000 +qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed. +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1835477 b/results/classifier/accel-gemma3:12b/vmm/1835477 new file mode 100644 index 000000000..6ceb8274d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1835477 @@ -0,0 +1,6 @@ + +Converting qcow2 to vmdk on MacOSX results in a non-bootable image + +When using qemu-img convert -O vmdk with version 3.1.0 or 4.0.0 on OSX (10.14.3) with a qcow2 image (https://cloud-images.ubuntu.com/bionic/20190703/bionic-server-cloudimg-amd64.img), the resulting image is not bootable. + +Running the same command on Ubuntu 18.04 results in a bootable image as expected \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1835729 b/results/classifier/accel-gemma3:12b/vmm/1835729 new file mode 100644 index 000000000..1d4c04997 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1835729 @@ -0,0 +1,10 @@ + +GTK display does not support host scale factor + +In the GNOME desktop environment, for HiDPI displays there is support to upscale everything. + +This can be set in "System Settings -> Displays -> Scale". + +I believe this affects GDK in the same way as setting the "GDK_SCALE" environment variable does. + +When launching `qemu-system-x86_64 ... -display gtk`, this scale factor seems to get lost; the result is that the host window is upscaled and doubled in size, while the guest appears only in the bottom left corner of the UI. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1835732 b/results/classifier/accel-gemma3:12b/vmm/1835732 new file mode 100644 index 000000000..03bbba16c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1835732 @@ -0,0 +1,12 @@ + +GTK display zoom in, zooms infinitely + +The zoom in feature in the "View" menu of the gtk frontend (launch qemu with -display gtk), seems to be very broken. + +If I hit the zoom in feature, it first zooms in. + +Then, it zooms in again. + +Every subsequent second that passes, it zooms in again, until it eventually eats up too much host resources and freezes the host desktop. + +I have seen this with 3.1.0 (Debian 1:3.1+dfsg-8~deb10u1), and also with a locally built 4.0, My colleague also confirms having seen the issue with 3.1.0 (Debian 1:3.1+dfsg-8). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1836537 b/results/classifier/accel-gemma3:12b/vmm/1836537 new file mode 100644 index 000000000..f80596610 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1836537 @@ -0,0 +1,11 @@ + +Kconfig-related options not shown in ./configure --help + +tag: v4.1.0-rc0 + +I notice these options not documented by '--help': + + --with-default-devices) default_devices="yes" + --without-default-devices) default_devices="no" + +We might have other options not documented too. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1837651 b/results/classifier/accel-gemma3:12b/vmm/1837651 new file mode 100644 index 000000000..a749ed835 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1837651 @@ -0,0 +1,16 @@ + +-netdev socket uses 100% cpu on Windows host + +On Windows hosts, any `-netdev socket` option (tcp listen, tcp connect, udp passing a fd) causes qemu to use 100% cpu. The guest still runs, but only sluggishly. + +A simple testcase is: + +> qemu-system-i386.exe -netdev socket,listen=:8000,id=n + +And, in another command prompt: + +> echo foo | nc.exe localhost 8000 + +Where nc.exe is netcat. + +Tested on qemu 3.1 (from https://qemu.weilnetz.de/w64/) and 4.0 (self compiled). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1837909 b/results/classifier/accel-gemma3:12b/vmm/1837909 new file mode 100644 index 000000000..86f57053b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1837909 @@ -0,0 +1,34 @@ + +test-char fails if host has no network interfaces + +# ./tests/test-char +# random seed: R02S8602535bf831a74bca571d8c416d8161 +1..34 +# Start of char tests +... +ok 12 /char/websocket +# Start of stdio tests +# End of stdio tests +# Start of socket tests +# Start of server tests +# Start of mainloop tests +Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: +# +# address resolution failed for 127.0.0.1:42275: Name or service not known +# + +Aborted (core dumped) + + +# ip a +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever + + +This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available + +This host setup may seem niche, but it is what the 'mock' RPM build tool has by default. In Fedora we run the test suite during the RPM build, so the failing test causes a bit of pain for certain workflows \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1838228 b/results/classifier/accel-gemma3:12b/vmm/1838228 new file mode 100644 index 000000000..865e6f692 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1838228 @@ -0,0 +1,19 @@ + +Slirp Broadcast traffic + +Hi all, + +Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1) + +I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server. + +DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets. + +Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?) + +Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.) + +WDYT? Did I miss some configuration options or use too old a version? + +Thanks, +Chris \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1838312 b/results/classifier/accel-gemma3:12b/vmm/1838312 new file mode 100644 index 000000000..5abe2ebb7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1838312 @@ -0,0 +1,32 @@ + +Qemu virt-manager Segmentation fault + +Hi! + +I installed all these packages: + +sudo apt install qemu +sudo apt install ipxe-qemu-256k-compat-efi-roms libspice-server1 libbluetooth3 +sudo apt install libbrlapi0.6 libcacard0 libfdt1 libusbredirparser1 libvirglrenderer0 libxen-4.9 libxenstore3.0 +sudo apt install cpu-checker ibverbs-providers ipxe-qemu libibverbs1 libiscsi7 libnl-route-3-200 librados2 librbd1 librdmacm1 msr-tools sharutils +sudo apt install qemu-block-extra qemu-system-common qemu-system-data qemu-system-gui qemu-utils +sudo apt install --no-install-recommends qemu-kvm qemu-system-x86 +sudo apt install libauparse0 ebtables gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 libvde0 libvdeplug2 libgovirt-common libgovirt2 libgtk-vnc-2.0-0 libgvnc-1.0-0 libosinfo-1.0-0 libphodav-2.0-0 libphodav-2.0-common libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5 libusbredirhost1 libvirt-clients libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt-glib-1.0-0 libvirt0 osinfo-db python3-libvirt python3-libxml2 spice-client-glib-usb-acl-helper vde2 vde2-cryptcab virt-viewer virtinst virt-manager + +without the i386 packages for Qemu because I want only 64 bit. + +I installed all these packages without error, but when I run + +# virt-manager + +Output: ...shows me: + +Segmentation fault + + +My hardware is 100% ok. +Maybee a broken lib? + + + +How can I fix that? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1839060 b/results/classifier/accel-gemma3:12b/vmm/1839060 new file mode 100644 index 000000000..3fa363b50 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1839060 @@ -0,0 +1,19 @@ + +HDA device non functional in Windows 10 1903 + +I made the update to 1903, and the HDA device stopped working. + +The driver says the device is working correctly, but it does not. +When I try to open the Windows sound configuration, the dialog hangs and never shows it's content. + +Several people reported this back in May: + +https://windowsreport.com/windows-10-v1903-ich6-ich9-virtio/ + +I can confirm I have exactly the same problem. + +Host is Arch Linux, current (5.2.5) kernel, QEMU 4.0. + +I enabled HDA debug output and compared an older, working Windows version to 1903, but could not see the difference. The driver seems to issue the same verbs. + +I am happy to provide additional information if needed. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1839294 b/results/classifier/accel-gemma3:12b/vmm/1839294 new file mode 100644 index 000000000..30f46de94 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1839294 @@ -0,0 +1,16 @@ + +Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation + +This happens on Windows 10 with the latest installer for 64 bit Windows: qemu-w64-setup-20190807.exe + +On install it will create the files and go through all the typical functions of installing the software, at the very end step it will then delete all files the installer created. + +I looked for logs to see when was going on so I ran the installation in Sandboxie and was able to retain all the installed files but I couldn't find a log for the installer. + +Here is a screenshot of it deleting all the files at the end of the process. + +https://imgur.com/BWiTA38 + +If goes too fast for me to see what is written in the text console otherwise I would post more information but this is all I have. It does not give any error or any other information at completion. + +This error does not occur in the earlier release: qemu-w64-setup-20190731.exe \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1840249 b/results/classifier/accel-gemma3:12b/vmm/1840249 new file mode 100644 index 000000000..bd6bf185b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1840249 @@ -0,0 +1,17 @@ + +Cancelling 'make docker-test-build' does not cancel running containers + +version: v4.1.0-rc5 + +Run 'make -k docker-test-build', wait a few, cancel with ^C: + +$ make -k docker-test-build 2>&1 > /dev/null +^C + +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS +62264a2d777a qemu:debian-mips-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +80807c47d0df qemu:debian-armel-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +06027b5dfd4a qemu:debian-amd64 "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes + +The docker containers are still up building QEMU. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1840250 b/results/classifier/accel-gemma3:12b/vmm/1840250 new file mode 100644 index 000000000..f863c082f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1840250 @@ -0,0 +1,16 @@ + +'make -j1 docker-test-build' uses more than one job + +version: v4.1.0-rc5 + +Run 'make -j1 docker-test-build', wait a few, various containers get instantiated. + +$ make -j1 docker-test-build 2>&1 > /dev/null + +On another terminal: + +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS +62264a2d777a qemu:debian-mips-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +80807c47d0df qemu:debian-armel-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +06027b5dfd4a qemu:debian-amd64 "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1842925 b/results/classifier/accel-gemma3:12b/vmm/1842925 new file mode 100644 index 000000000..774d3523d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1842925 @@ -0,0 +1,105 @@ + +no batmap on convertion from qcow2 to vhd + +we run following version of qemu-img: +$ qemu-img --version +qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.41), Copyright (c) 2004-2008 Fabrice Bellard +$ + +Here is os version: +$ cat /etc/os-release +NAME="Ubuntu" +VERSION="16.04.6 LTS (Xenial Xerus)" +ID=ubuntu +ID_LIKE=debian +PRETTY_NAME="Ubuntu 16.04.6 LTS" +VERSION_ID="16.04" +HOME_URL="http://www.ubuntu.com/" +SUPPORT_URL="http://help.ubuntu.com/" +BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" +VERSION_CODENAME=xenial +UBUNTU_CODENAME=xenial +$ + +When we use qemu-img for conversion of qcow2 to vhd newly created file doesnt show batmap summary when we run: + +# vhd-util read -p -n centos76.vhd +VHD Footer Summary: +------------------- +Cookie : conectix +Features : (0x00000002) <RESV> +File format version : Major: 1, Minor: 0 +Data offset : 512 +Timestamp : Mon Mar 4 13:21:27 2019 +Creator Application : 'qemu' +Creator version : Major: 5, Minor: 3 +Creator OS : Windows +Original disk size : 8192 MB (8590417920 Bytes) +Current disk size : 8192 MB (8590417920 Bytes) +Geometry : Cyl: 16645, Hds: 16, Sctrs: 63 + : = 8192 MB (8590417920 Bytes) +Disk type : Dynamic hard disk +Checksum : 0xfffff119|0xfffff119 (Good!) +UUID : 23772822-a66c-45a2-be37-8474604147c7 +Saved state : No +Hidden : 0 + +VHD Header Summary: +------------------- +Cookie : cxsparse +Data offset (unusd) : 18446744073709 +Table offset : 1536 +Header version : 0x00010000 +Max BAT size : 4097 +Block size : 2097152 (2 MB) +Parent name : +Parent UUID : 00000000-0000-0000-0000-000000000000 +Parent timestamp : Fri Dec 31 19:00:00 1999 +Checksum : 0xfffff466|0xfffff466 (Good!) + +# + +I am not so strong in VHD format details and not exactly sure how batmap is needed, but when I do conversion of qcow2 image by using vhd-util at the end I get file with proper batmap summary. + +In our environment we use CloudStack and Citrix and we use those converted from qcow2 to vhd images as templates. In general there is no problems, but whenever we create snapshot out of VM created from such template vhd-util read command starts giving us error like below: + +# +------------------- +Cookie : conectix +Features : (0x00000002) <RESV> +File format version : Major: 1, Minor: 0 +Data offset : 512 +Timestamp : Thu Aug 29 16:04:30 2019 +Creator Application : 'tap' +Creator version : Major: 1, Minor: 3 +Creator OS : Unknown! +Original disk size : 8194 MB (8592031744 Bytes) +Current disk size : 8194 MB (8592031744 Bytes) +Geometry : Cyl: 16648, Hds: 16, Sctrs: 63 + : = 8193 MB (8591966208 Bytes) +Disk type : Dynamic hard disk +Checksum : 0xfffff074|0xfffff074 (Good!) +UUID : 2b3cac7d-16e1-4771-b8cd-bb8c7876c761 +Saved state : No +Hidden : 0 + +VHD Header Summary: +------------------- +Cookie : cxsparse +Data offset (unusd) : 18446744073709 +Table offset : 1536 +Header version : 0x00010000 +Max BAT size : 4097 +Block size : 2097152 (2 MB) +Parent name : +Parent UUID : 00000000-0000-0000-0000-000000000000 +Parent timestamp : Sat Jan 1 00:00:00 2000 +Checksum : 0xfffff466|0xfffff466 (Good!) + +failed to get batmap header + +# + +With the templates that show correct batmap summary that are created by conversion of qcow2 image by vhd-util convert we don't have such problems. + +So I wanted to check with community if not existence of the batmap can cause (be the reason of) this behaviour later on snapshot creation stage? Should we always have batmap summary on output of vhd-util read command? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1843 b/results/classifier/accel-gemma3:12b/vmm/1843 new file mode 100644 index 000000000..c9e2d50ca --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1843 @@ -0,0 +1,16 @@ + +Multitouch - GTK: Tapping 3 points or more at too close in interval causes all points to be lost +Description of problem: +When using the new multitouch input device, if you use three or more fingers within two rapid interval, the all finger inputs get dropped. +Steps to reproduce: +ANDROID +1. Download and install BlissOS +2. Swipe with two fingers +3. try multitouch debug app + +FEDORA +1. Load fedora +2. install wev +3. try touch 3 or more points +Additional information: +Not sure what logs are relevant diff --git a/results/classifier/accel-gemma3:12b/vmm/1843852 b/results/classifier/accel-gemma3:12b/vmm/1843852 new file mode 100644 index 000000000..3a58c8c2f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1843852 @@ -0,0 +1,16 @@ + +QEMU does not express a dependency on perl-Test-Harness + +This is a minor thing; in Fedora you can install most of the developer dependencies by issuing something like `dnf builddep qemu-kvm` and this takes care of just about everything such that you can run ./configure and make. + +For "make check" though, configure doesn't catch that you'll need perl-Test-Harness; so it fails halfway through the check routine, and you'll see this: + +``` +Can't locate TAP/Parser.pm in @INC (you may need to install the TAP::Parser module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ./scripts/tap-driver.pl line 30. +BEGIN failed--compilation aborted at ./scripts/tap-driver.pl line 30. +make: *** [/home/jhuston/src/qemu/tests/Makefile.include:905: check-unit] Error 2 +``` + +I'm not sure how we should express this dependency; it shouldn't be a requirement for building, but it IS a dependency for testing. We probably ought not let users skip the qapi tests just because they don't have the perl requirement met. + +(And, separately, the Fedora package should list this as a builddep, but that's not an issue for here.) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1844 b/results/classifier/accel-gemma3:12b/vmm/1844 new file mode 100644 index 000000000..65013e540 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1844946 b/results/classifier/accel-gemma3:12b/vmm/1844946 new file mode 100644 index 000000000..0f6604675 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1844946 @@ -0,0 +1,30 @@ + +macOS HVF broken with WinXP after Aug 21 2018 92d5f1a414 + +I use macOS with own built Qemu to run old XP system that I have migrated from physical machine. My setup is very simple qemu-system-x86_64 with args: +-machine pc,accel=hvf,usb=off,vmport=off +-cpu host +-vga std +-m 2048 +-drive file="$img",format=qcow2,cache=none,detect-zeroes=on +-usb -device usb-tablet + +Unfortunately as soon I enable HVF with first 2 lines WinXP SP3 hangs on boot (famous mup.sys). It works fine in TCG. + +I dived into the code checking the differences between HVF, KVM and HAXM and my analysis is: + +1. Sergio Andres Gomez Del Real b7394c8394 - replaces explicit VMCS_GUEST_INTERRUPTIBILITY checks with hflags/hflags2. + +2. Paolo Bonzini 92d5f1a414 - changes hflags/hflags2 behavior which breaks in the end HVF interrupt handling and makes WinXP unable to boot. NOTE: This does not break I believe KVM and HAXM as they still do explicit check instead what HVF does in 1. That's why it was probably not reported and Qemu macOS users are rather niche ;) + +Reverting 92d5f1a414 makes WinXP boot well and work flawlessly. +Unfortunately b7394c8394 is not easy anymore as too many changes on the way, so it may be not an option. + +This can be reproduced simply by installing /Users/ono/VM/ISO/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso +with HAL as "Standard PC" selectable with F5 on first run. + +I can also provide fresh ~600MB qcow2 image (without activation key entered yet) that is created before boot that fails. No need for full XP installation to test that. + +Nevertheless I would really appreciate Paolo looking into this. +Many thanks for great software, +Adam \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1847861 b/results/classifier/accel-gemma3:12b/vmm/1847861 new file mode 100644 index 000000000..99a418c2c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1847861 @@ -0,0 +1,31 @@ + +Guest stuttering under high disk IO (virtio) + +Performing io intensive tasks on virtualized Windows causes the system to visually stutter. I can often reproduce the problem by running fio on windows: + +fio --randrepeat=1 --ioengine=windowsaio --direct=1 --gtod_reduce=1 --name=test --filename=\\.\PhysicalDrive0 --bs=4k --iodepth=128 --size=4G --readwrite=randread + +While the fio command is running, moving the mouse pointer will be be laggy. The stuttering does not appear with iodepth <= 32 . The stuttering also manifests while playing games, the music and video pauses for a fraction of second in a playable but disturbing way. + +Here are my system specs: + +Host OS: archlinux +Guest OS: Windows 10 Enterprise +qemu version: qemu-git 8:v4.1.0.r1378.g98b2e3c9ab-1 (from AUR, compiled with -march=native) +CPU: AMD Ryzen Threadripper 1900X 8-Core Processor +Huge Pages: vm.nr_hugepages=4128 +Disk: nvme type=raw, io=threads bus=virtio +GPU (passthrough): Radeon RX 570 + +Here are some fio test results on my windows guest: + +[size=512M,iodepth=1 -> min=30k,avg=31k,stddev=508] +[size=2G,iodepth=8 -> min=203k,avg=207k,stddev=2.3k] +[size=2G,iodepth=16 -> min=320k,avg=330k,stddev=4.3k] +[size=4G,iodepth=32 -> min=300k,avg=310k,stddev=4.8k] +[size=4G,iodepth=64 -> min=278k,avg=366k,stddev=68.6k] -> STUTTER +[size=4G,iodepth=64 -> min=358k,avg=428k,stddev=52.6k] -> STUTTER +[size=4G,iodepth=128 -> min=92k,avg=217k,stddev=185k] -> STUTTER +[size=4G,iodepth=128 -> min=241k,avg=257k,stddev=14k] -> same config as above, but no stuttering + +The min and avg values are the bandwidth values reported in KB/s by fio. You can see that, when the stuttering occurs, the stardard deviation is high and the minimum bandwidth is way below the average. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1849644 b/results/classifier/accel-gemma3:12b/vmm/1849644 new file mode 100644 index 000000000..096ddacf6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1849644 @@ -0,0 +1,14 @@ + +QEMU VNC websocket proxy requires non-standard 'binary' subprotocol + +When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version. + +When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect. + +One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior. + +Looking at the code in "io/channel-websock.c" it seems it's quite hard-coded to binary: + +Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c + +This code has to be made more dynamic, and shouldn't require binary. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1850000 b/results/classifier/accel-gemma3:12b/vmm/1850000 new file mode 100644 index 000000000..f04995c93 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1850000 @@ -0,0 +1,81 @@ + +4.1.0 bogus QCOW2 corruption reported after compress + +Creating a compressed image then running `qemu-img check <..>.qcow2' on said image seems to report bogus corruption in some (but not all) cases: + +Step 1. + +# qemu-img info win7-base.qcow2 +image: win7-base.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 12.2 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: false + +# qemu-img check win7-base.qcow2 +No errors were found on the image. +327680/327680 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters +Image end offset: 21478375424 + +Step 2. + +# qemu-img convert -f qcow2 -O qcow2 -c win7-base.qcow2 test1-z.qcow2 + +Step 3. + +# qemu-img info test1-z.qcow2 +image: test1-z.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 5.78 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# qemu-img check test1-z.qcow2 +ERROR cluster 1191 refcount=1 reference=2 +ERROR cluster 1194 refcount=1 reference=4 +ERROR cluster 1195 refcount=1 reference=7 +ERROR cluster 1196 refcount=1 reference=7 +ERROR cluster 1197 refcount=1 reference=6 +ERROR cluster 1198 refcount=1 reference=4 +ERROR cluster 1199 refcount=1 reference=4 +ERROR cluster 1200 refcount=1 reference=5 +ERROR cluster 1201 refcount=1 reference=3 +<...> snip many errors +Leaked cluster 94847 refcount=3 reference=0 +Leaked cluster 94848 refcount=3 reference=0 +Leaked cluster 94849 refcount=11 reference=0 +Leaked cluster 94850 refcount=14 reference=0 + +20503 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +20503 leaked clusters were found on the image. +This means waste of disk space, but no harm to data. +197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters +Image end offset: 6216220672 + + +The resultant image seems to work fine in a VM when used as a backing file. + +Interestingly, if I substitute a qemu-img binary from qemu-4.0 then no errors are reported. + +# /tmp/qemu-img check test1-z.qcow2 +No errors were found on the image. +197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters +Image end offset: 6216220672 + +Is the image corrupted or not? I'm guessing not. + +Just in case it matters, this is ext4 fs on rotational disk. Latest Arch Linux but self compiled 4.1.0 with recent QCOW2 corruption fixes added. + +I haven't tried latest trunk but might do so if time permits. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1851972 b/results/classifier/accel-gemma3:12b/vmm/1851972 new file mode 100644 index 000000000..4e764352e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1851972 @@ -0,0 +1,60 @@ + +pc-q35-4.1 and AMD Navi 5700/XT incompatible + +Hello, + +I am not sure if this qualifies as a "bug"; it is be more of an unknown issue with default settings. However, since the default value of q35 default_kernel_irqchip_split was changed seemingly due to similar user feedback, I thought this was important to share.. + +AMD Navi 5700/XT vfio-pci passthrough seems incompatible with one/multiple settings in pc-q35-3.1 and higher. The workaround for me is that pc-q35-3.0 still works fine passing through the GPU and official drivers can load/install fine. + +The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest do work; the monitor displays the desktop in a 800x600 resolution and things are rendered fine.. so the basic functionality of the card seems fine with pc-q35-4.1. + +But attempting to use the official open source AMD driver with the card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on the Windows 1903 guest immediately during driver install. + +I do not see any errors in Qemu command output.. did not investigate other logs or KVM etc, because I am not sure what to look for or how to go about it. Also not sure which combination of the latest q35 default settings are valid combinations to try either, because it seems that multiple things have changed related to pcie-root-port defaults and other machine options. I am happy to run tests and provide feedback if that helps identify the issue. + +I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host with AMD Navi reset pci quirk patch applied. + +My working Qemu command line is this: + +QEMU_AUDIO_DRV=pa \ +QEMU_PA_SERVER=/run/user/1000/pulse/native \ +/usr/bin/qemu-system-x86_64 \ +-name windows \ +-m 16g \ +-accel kvm \ +-machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \ +-blockdev node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \ +-blockdev node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \ +-boot menu=on \ +-global kvm-pit.lost_tick_policy=discard \ +-no-hpet \ +-rtc base=utc,clock=host,driftfix=slew \ +-cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \ +-smp sockets=1,cores=4,threads=1 \ +-nodefaults \ +-netdev bridge,br=br0,id=net0 \ +-device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \ +-device virtio-scsi-pci \ +-blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \ +-device scsi-hd,drive=disk0,rotation_rate=1 \ +-blockdev raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw \ +-device scsi-hd,drive=disk1,rotation_rate=1 \ +-drive index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso \ +-drive index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso \ +-device ich9-intel-hda,addr=1b.0 \ +-device hda-output \ +-monitor stdio \ +-display none \ +-vga none \ +-device pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on \ +-device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \ +-device x3130-upstream,bus=pcierp0,id=pcieu0 \ +-device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \ +-device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \ +-device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \ +-device qemu-xhci,addr=1d.0 \ +-device usb-host,vendorid=0x258a,productid=0x0001 \ +-device usb-host,vendorid=0x1bcf,productid=0x0005 ; + +Thank you! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1854204 b/results/classifier/accel-gemma3:12b/vmm/1854204 new file mode 100644 index 000000000..65a91beb0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1854204 @@ -0,0 +1,7 @@ + +Menu is not clickable on OSX Catalina + +1) Run `qemu-system-x86_64` +2) Try to click on the main menu + +Menu is not clickable until another window is activated and QEMU window is activated again \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1854910 b/results/classifier/accel-gemma3:12b/vmm/1854910 new file mode 100644 index 000000000..ee50e39c2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1854910 @@ -0,0 +1,4 @@ + +Support VHDX differencing images (ie images with backing) + +The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1855535 b/results/classifier/accel-gemma3:12b/vmm/1855535 new file mode 100644 index 000000000..bcf49f72c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1855535 @@ -0,0 +1,43 @@ + +Connection reset by peer when using port fwd + +$ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp cores=8 -serial mon:stdio -nographic \ +-drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \ +-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +-cdrom /qemu/aix72.iso \ +-prom-env boot-command='boot disk:' \ +-name ctsprod -k es \ +-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \ +-device virtio-net-pci,netdev=netdev0 \ +-netdev bridge,id=hostnet0,br=virbr0 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \ +-device virtio-net,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0,script=no,downscript=no \ +-monitor telnet:127.0.0.1:5801,server,nowait,nodelay + + +$ ssh -p 2222 root@127.0.0.1 -v + +OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 +debug1: Reading configuration data /etc/ssh/ssh_config +debug1: /etc/ssh/ssh_config line 19: Applying options for * +debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222. +debug1: Connection established. +debug1: permanently_set_uid: 0/0 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_rsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_rsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_dsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_dsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ecdsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ecdsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ed25519 type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ed25519-cert type -1 +debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 +ssh_exchange_identification: read: Connection reset by peer \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1855617 b/results/classifier/accel-gemma3:12b/vmm/1855617 new file mode 100644 index 000000000..97f91b8f9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1855617 @@ -0,0 +1,5 @@ + +savevm with hax saves wrong register state + +I use qemu-i386 with IntelHaxm on Windows 10 x64 host with Windows 7 x86 guest. I run the guest till OS loads and create a snapshot with savevm, then close qemu, run it again and try to load the snapshot with loadvm. The guest crashes or freezes. I dumped registers on snapshot creation and loading (in Haxm) and found that they are different. +When returning from Haxm in hax_vcpu_hax_exec, there is no regular register read. I found hax_arch_get_registers function which reads registers from Haxm and is called from a synchronization procedure. I placed a breakpoint on it, ran qemu and found that it is hit one time during guest OS boot. Exactly these registers where saved in the snapshot. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1857269 b/results/classifier/accel-gemma3:12b/vmm/1857269 new file mode 100644 index 000000000..281acb3aa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1857269 @@ -0,0 +1,16 @@ + +Keyboard not fully working on Windows version + +Hello, + +I am working with windows qemu version: + +qemu-w64-setup-20190815 + +I have installed a msdos virtual machine on qemu with sp keyboard layout (Spain at Europe). I have found that some keys do not work in the way they should. I believe that the problem is that es qemu spanish keyboard layout is the latin one, la in msdos sysytem. + +I ask you to create the Spain layout. + + + +Thanks in advance. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1858623 b/results/classifier/accel-gemma3:12b/vmm/1858623 new file mode 100644 index 000000000..971eea27d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1858623 @@ -0,0 +1,15 @@ + +VNC outputs garbage in zlib mode + +TL;DR: When QEMU is launched with VNC as the output and viewed with a client that defaults to zlib VNC encoding, the resulting output tends to accumulate artifacts. + +Reproduction: +Launch QEMU (tried with versions 4.2.0 and 4.1.0 on Linux 64bit) with -vnc 0.0.0.0:0 +Connect to it with a VNC client that allows you to select encoding, i.e. UltraVNC. +Set encoding to zlib (type 6), 32bit color. +As screen content changes it starts accumulating artifacts. Almost certain to appear if you open-close windows over a pattern. +Does not seem to depend on guest used, but easier to reproduce with a GUI. + +Looks like this: https://orbides.org/img/vnc.png + +It appears to be a deflate glitch of some sort - all of the bad pixels are generated by length/distance codes. Can't narrow it down any more. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1859081 b/results/classifier/accel-gemma3:12b/vmm/1859081 new file mode 100644 index 000000000..8aa0bf148 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1859081 @@ -0,0 +1,9 @@ + +Mouse way too fast when Qemu is on a Windows VM with a OS 9 Guest + +On a server, I have a Windows 10 VM with Qemu 4.1.0 (latest) from https://qemu.weilnetz.de/w64/ installed. +There I have a Mac OS 9.2.2 machine. +Now if I connect to the Windows VM with VNC or RDP or even VMWare console, the Mouse in the Mac OS Guest inside Qemu is waaaay to fast. Even when lowering the mouse speed in the Mac OS mouse setting, one pixel in the Host (Windows 10 VM) still moves the mouse by 10 pixels inside the Qemu machine. +I tried different resolutions but that does not help. +Is there any way to fix this or any way how I can provide more information? +Thanks \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1859254 b/results/classifier/accel-gemma3:12b/vmm/1859254 new file mode 100644 index 000000000..4d36bf617 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1859254 @@ -0,0 +1,32 @@ + +host window size does not change when guest video screen size changes while moving host window + +When QEMU is emulating a legacy text mode, then switches to a VESA mode, if you happen to be moving the host window while the switch is made, the host window never changes size. The emulated size does, but the host window doesn't. + +For example, at Legacy boot up, the screen mode is mode 03 at 80x25. Then when the GUEST OS changes the screen to a VESA mode, say 1024x768x16, normally the host window will change to that size to accommodate the new emulated screen size. + +However, if you happen to be moving the host window at the time of the screen mode change, the host window doesn't change in size to accommodate the new screen size. + +I am using: + QEMU for Windows, version 4.1.0-11789 + Host: Windows 10 (latest updates) + Emulating: Intel x64, Legacy BIOS +Command line: +"c:\program files\qemu\qemu-system-x86_64.exe" -m 256 -drive file=C:\fysos64.img,format=raw,if=ide,media=disk,index=0 -parallel file:para.txt -boot c -d guest_errors -vga std -smp cpus=4 -rtc base=localtime,clock=host,driftfix=slew -net none -monitor stdio + +I tried different -vga settings: + -vga std + -vga cirrus + -vga vmware +Each did the same thing. + +[ Side note (possible error in documentation): +[ at: https://qemu.weilnetz.de/doc/qemu-doc.html#SVGA-graphic-modes-support +[ end of 2.16.2.1 +[ (option -std-vga) +[ possibly should be +[ (option -vga std) + +If you need an image to test with, I have been using www.fysnet.net/temp/fysos64.zip (2meg zipped/10meg raw). It starts in Legacy BIOS/Hardware mode 3, then switches to VESA 1024x768x16 within a few seconds, so be ready to move the HOST window when the mode changes. + +I do not have a Linux box to test with, so unknown if this is only an issue with the Windows version or not. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1860 b/results/classifier/accel-gemma3:12b/vmm/1860 new file mode 100644 index 000000000..c481d4dd3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1860 @@ -0,0 +1,11 @@ + +virtio-gpu: Only black screen observed after resuming when guest vm do S3 +Description of problem: +On Xen hypervisor, host(dom0) is PVH, guest(domU) is hvm, config virtio-gpu for guest. + +## +Steps to reproduce: +1. In guest vm run "sudo su root" & "echo mem \> /sys/power/state" +2. In host run "sudo xl trigger \<guest id\> s3resume" +Additional information: +## diff --git a/results/classifier/accel-gemma3:12b/vmm/1861458 b/results/classifier/accel-gemma3:12b/vmm/1861458 new file mode 100644 index 000000000..8a131b412 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1861458 @@ -0,0 +1,15 @@ + +Clock drift issue with -soundhw hda + +Here's the scenario: I'm working on code for loopback audio recording (i.e. recording what you're hearing) using WASAPI on Windows. As I usually develop on Linux, I'm using qemu to test this on a Windows 10 VM. The heart of WASAPI audio recording is the IAudioCaptureClient::GetBuffer function (https://docs.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudiocaptureclient-getbuffer). Among other things, this function produces a timestamp for when the audio buffer it returned is supposed to be played. + +When the audio device in question is the qemu hda device, this timestamp is wrong. + +There is a clock drift error (I measured it to be about 0.1%, i.e. 1ms drift every second = a full second after 16 minutes) that causes the audio clock to advance faster than the system clock. Paradoxically, this does not affect audio playback through qemu at all, no delay there. Only the timestamps returned to recording applications are completely bogus. + +Unfortunately I'm not intimately familiar with the inner workings of Intel HD Audio. All I can tell you is that this timestamp is supposedly obtained directly from the hardware (which would be qemu in this case), which is also why e.g. chromium implements a workaround for buggy hardware that returns incorrect timestamps. + +Here are the relevant parts of my command line (version 4.2.0): +-enable-kvm -machine pc-q35-3.1,kernel-irqchip=on -cpu host,kvm=off,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=NvidiaFuckU -rtc base=localtime -nodefaults -soundhw hda + +Just wanted to let you know about this because it took me three days of utter confusion and frustration to figure this out. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1861692 b/results/classifier/accel-gemma3:12b/vmm/1861692 new file mode 100644 index 000000000..f97aefbc2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1861692 @@ -0,0 +1,4 @@ + +wavcapture does not record silence + +Using setup described in https://bugs.launchpad.net/qemu/+bug/1861677 a wav file is generated with all the silences stripped out. IOW silence frames are not recorded. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1861884 b/results/classifier/accel-gemma3:12b/vmm/1861884 new file mode 100644 index 000000000..d0650a3ff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1861884 @@ -0,0 +1,22 @@ + +qemu socket multicast not working + +Running two qemu vms on the same socket multicast address: + + qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none + -nodefaults -accel hax + -netdev user,id=mynet0 + -device virtio-net-pci,netdev=mynet0 + -netdev socket,id=vlan,mcast=239.192.0.1:1235 + -device virtio-net-pci,netdev=vlan + -device virtio-rng-pci + -drive file=worker.qcow2,if=virtio + -drive file=cloud-init.iso,format=raw,if=virtio + +The two machines have a static ip on the socket network interface, 192.168.100.11 and 192.168.100.12, but are unable to reach each other. + +Is there additional configuration necessary on macos? Does this only work on Linux? + +guest OS: Debian 10 (Buster) +host OS: macOS 10.15.2 +qemu: 4.2.0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1862979 b/results/classifier/accel-gemma3:12b/vmm/1862979 new file mode 100644 index 000000000..bfa8eb189 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1862979 @@ -0,0 +1,16 @@ + +Cannot Create Socket Networking in Windows Host using Multicast + +Hello QEMU devs, + +I am trying to create a simulated VLAN using socket networking, and the only way to connect multiple networks in QEMU using socket networking is by using the multicast `mcast` option of the `socket` network backend. + +However, when I try use the following arguments in QEMU to create a multicast socket network: + +`-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234` + +it fails with: + +`can't bind ip address=230.0.0.1: unknown error` in my Windows host. + +I would like to know if this is a bug, or if I am missing a prerequisite before running the QEMU command. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1863023 b/results/classifier/accel-gemma3:12b/vmm/1863023 new file mode 100644 index 000000000..8866ee955 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1863023 @@ -0,0 +1,39 @@ + +Deadlock in QXL + +This is on qemu 4.2.0 OSX host, running fresh Windows 7 with SPICE guest tools just installed. + +Command line: `qemu-system-x86_64 -qmp tcp:localhost:4444,server,nowait -smp cpus=2 -boot order=d -m 2048 -soundhw hda -drive file=hda.img,if=ide,media=disk -spice port=5930,addr=127.0.0.1,disable-ticketing,image-compression=off,playback-compression=off,streaming-video=off -vga qxl -device rtl8139,netdev=net0 -netdev user,id=net0` + +After the Windows logo, the screen is black. I dump the two vCPU threads: + +``` +* thread #16 + * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10 + frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701 + frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e8d0, mutex=0x000000011120ba48, file="cpus-common.c", line=144) at qemu-thread-posix.c:173:11 [opt] + frame #3: 0x0000000110926a59 qemu-system-x86_64`do_run_on_cpu(cpu=<unavailable>, func=<unavailable>, data=<unavailable>, mutex=0x000000011120ba48) at cpus-common.c:144:9 [opt] + frame #4: 0x000000011080c50a qemu-system-x86_64`memory_region_snapshot_and_clear_dirty at memory.c:2595:5 [opt] + frame #5: 0x000000011080c4d7 qemu-system-x86_64`memory_region_snapshot_and_clear_dirty(mr=<unavailable>, addr=0, size=2359296, client=<unavailable>) at memory.c:2107 [opt] + frame #6: 0x0000000110849fe1 qemu-system-x86_64`vga_update_display [inlined] vga_draw_graphic(s=<unavailable>, full_update=0) at vga.c:1661:16 [opt] + frame #7: 0x000000011084996a qemu-system-x86_64`vga_update_display(opaque=<unavailable>) at vga.c:1785 [opt] + frame #8: 0x00000001109b261d qemu-system-x86_64`qxl_hard_reset(d=0x00007f84f8730000, loadvm=0) at qxl.c:1285:5 [opt] + frame #9: 0x000000011080ac97 qemu-system-x86_64`memory_region_write_accessor(mr=0x00007f84f8741fb0, addr=5, value=<unavailable>, size=1, shift=<unavailable>, mask=<unavailable>, attrs=MemTxAttrs @ 0x000070000786d890) at memory.c:483:5 [opt] + frame #10: 0x000000011080ab31 qemu-system-x86_64`memory_region_dispatch_write [inlined] access_with_adjusted_size(addr=<unavailable>, value=0x00000000015c6100, size=<unavailable>, access_size_min=<unavailable>, access_size_max=<unavailable>, access_fn=<unavailable>, mr=<unavailable>, attrs=<unavailable>) at memory.c:544:18 [opt] + frame #11: 0x000000011080aafd qemu-system-x86_64`memory_region_dispatch_write(mr=<unavailable>, addr=<unavailable>, data=22831360, op=32644, attrs=MemTxAttrs @ 0x000070000786d8c0) at memory.c:1475 [opt] + frame #12: 0x00000001107b080d qemu-system-x86_64`address_space_stb(as=<unavailable>, addr=<unavailable>, val=22831360, attrs=MemTxAttrs @ r12, result=0x0000000000000000) at memory_ldst.inc.c:378:13 [opt] + frame #13: 0x0000000118570230 + +* thread #18 + * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10 + frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701 + frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e860, mutex=0x000000011121e818, file="cpus-common.c", line=196) at qemu-thread-posix.c:173:11 [opt] + frame #3: 0x0000000110926c44 qemu-system-x86_64`start_exclusive at cpus-common.c:196:9 [opt] + frame #4: 0x0000000110837c35 qemu-system-x86_64`cpu_exec_step_atomic(cpu=0x00007f8518290000) at cpu-exec.c:265:9 [opt] + frame #5: 0x00000001107fcf95 qemu-system-x86_64`qemu_tcg_cpu_thread_fn(arg=0x00007f8518290000) at cpus.c:1799:17 [opt] + frame #6: 0x0000000110bf911e qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:519:9 [opt] + frame #7: 0x00007fff52466e65 libsystem_pthread.dylib`_pthread_start + 148 + frame #8: 0x00007fff5246283b libsystem_pthread.dylib`thread_start + 15 +``` + +Seems like thread #16 had a STB to QXL MMIO registers which caused it to call `qxl_hard_reset` and eventually made its way to `do_run_on_cpu` which waits for `qemu_work_cond`. The only way `qemu_work_cond` is set is if one of the two vCPU executes the queued work at the end of the TCG execution. Thread #16 is stuck waiting, so what about thread #18? Thread #18 is waiting for `exclusive_cond` which is set once all the other CPUs are done running (but thread #16 is waiting still). So classic deadlock. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1863096 b/results/classifier/accel-gemma3:12b/vmm/1863096 new file mode 100644 index 000000000..c3c80c300 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1863096 @@ -0,0 +1,67 @@ + +vhost-user multi-queues interrupt failed when Qemu reconnection happens + +After upgrade qemu to v4.2.0, vhost-user multi-queues interrupt failed with event idx interrupt mode when reconnection happens. + +Test Environment: +DPDK version: DPDK v19.11 +Other software versions: qemu 4.2.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 +Hardware platform: Purley. + +The reproduce step is: +1. Launch l3fwd-power example app with client mode:: + + ./l3fwd-power -l 1-16 \ + -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ + --log-level=9 \ + --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ + -- -p 0x1 \ + --parse-ptype 1 \ + --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" + +2. Launch VM1 with server mode: + +3. Relauch l3fwd-power sample to for reconnection: + + ./l3fwd-power -l 1-16 \ + -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ + --log-level=9 \ + --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ + -- -p 0x1 \ + --parse-ptype 1 \ + --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" + +4. Set vitio-net with 16 quques and give vitio-net ip address: + + ethtool -L [ens3] combined 16 # [ens3] is the name of virtio-net + ifconfig [ens3] 1.1.1.1 + +5. Send packets with different IPs from virtio-net, notice to bind each vcpu to different send packets process:: + + taskset -c 0 ping 1.1.1.2 + taskset -c 1 ping 1.1.1.3 + taskset -c 2 ping 1.1.1.4 + taskset -c 3 ping 1.1.1.5 + taskset -c 4 ping 1.1.1.6 + taskset -c 5 ping 1.1.1.7 + taskset -c 6 ping 1.1.1.8 + taskset -c 7 ping 1.1.1.9 + taskset -c 8 ping 1.1.1.2 + taskset -c 9 ping 1.1.1.2 + taskset -c 10 ping 1.1.1.2 + taskset -c 11 ping 1.1.1.2 + taskset -c 12 ping 1.1.1.2 + taskset -c 13 ping 1.1.1.2 + taskset -c 14 ping 1.1.1.2 + taskset -c 15 ping 1.1.1.2 + +If everything ok, then we can see the result such as following: + + L3FWD_POWER: lcore 0 is waked up from rx interrupt on port 0 queue 0 + ... + ... + L3FWD_POWER: lcore 15 is waked up from rx interrupt on port 0 queue 15 + +But we can't see the log above because of the bug. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1863601 b/results/classifier/accel-gemma3:12b/vmm/1863601 new file mode 100644 index 000000000..0e5b72ea0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1863601 @@ -0,0 +1,4 @@ + +unable to type "|" character in french keyboard. + +Unable to type "|" character when using french keyboard. It is displaying "<" instead of pipe. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1864814 b/results/classifier/accel-gemma3:12b/vmm/1864814 new file mode 100644 index 000000000..98f7b1524 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1864814 @@ -0,0 +1,15 @@ + +Improve UX for macOS when launching from a fullscreen app + +System/setup: +* MacBook Pro, macOS (any version from the last 2 years), external monitor. +* IDE on the laptop, emulator is used on the external monitor. + +Currently, when starting the emulator from e.g. Android Studio or IntelliJ IDEA, which is set to fullscreen mode on the laptop, which is like it's own virtual desktop (Space) in macOS, what happens is this: + +1. The virtual desktop (Space) on the laptop screen is switched because of #2. The reason is that only one window can be shown in Fullscreen this way. +2. The qemu splashscreen is shown for a few seconds, then it disappears. This is the reason for the virtual desktop switch. This splashscreen seems actually unnecessary to me, it has no value and it causes problems. +3. The actual emulator is shown, in my case on the external monitor (correctly). I guess if the splashscreen would not be shown, the virtual desktop switch would not happen, because the emulator would happen on the correct screen directly. + +So maybe the splashscreen and the emulator window should be the same window, so that the OS can remember it's position being the same as the emulator? +Or maybe the splash could be disabled (by default? otherwise an update to IDEs would be necessary for the improved behavior?) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1864955 b/results/classifier/accel-gemma3:12b/vmm/1864955 new file mode 100644 index 000000000..0635d3a84 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1864955 @@ -0,0 +1,10 @@ + +bundle QEMU installer with HAXM accelerator for Windows + +As you probably know HAXM is an accelerator for Windows. + +https://www.qemu.org/2017/11/22/haxm-usage-windows/ + +Currently it is required to first install QEMU and then install HAXM. + +For a better out of the box user experience on the Windows platform it would be nice if QEMU and HAXM would be installed by the same installer. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1864984 b/results/classifier/accel-gemma3:12b/vmm/1864984 new file mode 100644 index 000000000..8d0b874af --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1864984 @@ -0,0 +1,10 @@ + +"nr_entries is too big" when using virgl + +I have a bootable image where GNOME Shell fails because it hits a limit in virtio-gpu. + +In `hw/display/virtio-gpu.c`, there is a limit for `nr_entries` at 16384. There is no explanation for that limit. But there does not seem to be any limit on the kernel side. + +Raising this limit with a patch to 262144 solves the issue. + +Could there be an explanation why this limit is needed? And why this value? Or could this limit be just removed? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1865248 b/results/classifier/accel-gemma3:12b/vmm/1865248 new file mode 100644 index 000000000..d293be5b6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1865248 @@ -0,0 +1,12 @@ + +bundle QEMU installer with a QEMU GUI (graphical user interface) such as Virt Manager + +For a better out of the box user experience on the Windows platform it would be nice if a QEMU GUI would be by installed by the same QEMU installer. Currently it is required to first install QEMU and then install a QEMU GUI. + +I don't know all QEMU GUIs but looks like Virt Manager is a decent QEMU GUI and still maintained. + +Virt Manager is also available for Windows. + +https://serverfault.com/questions/340949/is-there-a-way-to-run-virt-manager-on-windows + +However as per these instructions it is difficult (many steps) for laymen to install Virt Manager on Windows (cygwin...). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1865252 b/results/classifier/accel-gemma3:12b/vmm/1865252 new file mode 100644 index 000000000..ce11aaba3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1865252 @@ -0,0 +1,34 @@ + +QEMU Windows Portable Version (with HAXM accelerator and QEMU GUI) + +Please consider providing a QEMU Windows portable [1] [2] [3] version on official qemu.org. + +Reasons: + +* This would improve usability, the out of the box user experience of laymen (non-technical) users. +* Linux distributions could add the QEMU Windows portable to their installer / live ISO images (and the DVD's autorun.inf). Users who are still running on the Windows platform could be having an easy path to try out a Linux distribution by running int inside QEMU. I've seen that in many some years ago. Was running Windows. Just open the DVD drive in Windows explorer, double click and QEMU (shipped with the ISO) booted the ISO. + +Ideally EMU Windows portable version would be bundled with: + +* the [QEMU HAXM accelerator] by default. Related ticket: [5] +* a QEMU GUI by default. Related ticket: [6] + + +[1] When I say "Windows Portable" I mean "USB portable". [4] + +[2] A compress archive (zip or so) which after extraction can be executed without further installation / setup required. As far I know [https://portableapps.com portableapps.com] is the most popular project of that kind. + +[3] QEMU might already be portable or mostly portable. See: + +* https://portableapps.com/search/node/QEMU +* https://www.google.com/search?hl=en&q=site%3Aportableapps.com%20QEMU%20portable +* https://www.portablefreeware.com/?id=640 +* https://willhaley.com/blog/simple-portable-linux-qemu-vm-usb/ + +But not sure above projects are still maintained. Would be certainly better if official qemu.org would be providing a QEMU Windows portable version. + +[4] Or more generally "can be run on any external storage medium on any Windows [10] computer. + +[5] https://bugs.launchpad.net/qemu/+bug/1864955 + +[6] https://bugs.launchpad.net/qemu/+bug/1865248 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1865350 b/results/classifier/accel-gemma3:12b/vmm/1865350 new file mode 100644 index 000000000..686941399 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1865350 @@ -0,0 +1,32 @@ + +fstrim not working with image mounted to path? + + +guest os: windows server standard 2016 +qemu agent version 100.0.0 + +os supports trimming +path mounted image does not support trimming + +C:\Users\Administrator>fsutil behavior query disabledeletenotify +NTFS DisableDeleteNotify = 0 +ReFS DisableDeleteNotify = 1 + + +[@ ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\xxxx\\","error":"The given volume path is invalid. (0x89000001)"}]}} + + +Looks like the fstrim does not like/check images mounted on a path? Nor detects if image trimming is supported. xxxx is a ReFS mounted image without trimming support. + +If I enable trimming on the ReFS image, and configure it win2016, the result is still the same. + + +C:\Users\Administrator>fsutil behavior query disabledeletenotify +NTFS DisableDeleteNotify = 0 +ReFS DisableDeleteNotify = 0 + +[root@c03 ~]# virsh qemu-agent-command vps-xxx '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"path":"C:\\"},{"path":"C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\xxxx\\","error":"The given volume path is invalid. (0x89000001)"}]}} + +PS. tried this on a win 2016 std server with just one fs, no problems then. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1866792 b/results/classifier/accel-gemma3:12b/vmm/1866792 new file mode 100644 index 000000000..ac69a5675 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1866792 @@ -0,0 +1,62 @@ + +formating vdi-disk over nbd fails + +Hi, +after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd partitioning works fine, but the system hangs up during formating with mkfs.ext4. + +Same procedure with qcow2-image works fine +Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + + +----------------- +#! /bin/sh + +qemu-img create -f qcow2 ~/test.qcow2 32G +#qemu-img version 4.1.1 (qemu-4.1.1-1.fc31) + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd2 ~/test.qcow2 +#qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31) + +parted -s /dev/nbd2 "mklabel gpt" +parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd2 "p" + +mkfs.ext4 /dev/nbd2p1 +#Format hangs up due to IO errors. +#Tested on Fedora 31, kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_qcow2 + +mount /dev/nbd2p1 /mnt/test_qcow2 +df -H + +------------------- +#! /bin/sh + +qemu-img create -f vdi ~/test.vdi 32G + +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd4 ~/test.vdi + +parted -s /dev/nbd4 "mklabel gpt" +parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G " +parted -s -a optimal /dev/nbd4 "p" + +mkfs.ext4 /dev/nbd4p1 +#Format hangs up due to IO errors +#Tested on Fedora 31 kernel 5.5.7-200.fc31.x86_64 + +mkdir /mnt/test_vdi + +mount /dev/nbd4p1 /mnt/test_vdi +df -H +---------------------- + + +Kind regards + Eilert + +PS.: There may be a connection to this bug: + +#1661758 qemu-nbd causes data corruption in VDI-format disk images \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1867601 b/results/classifier/accel-gemma3:12b/vmm/1867601 new file mode 100644 index 000000000..af9527c1e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1867601 @@ -0,0 +1,16 @@ + +test-char not concurrent with unix socket + +'make check-unit' might fail when running multiple tests in parallel. + +Apparently occurred on OSX CI: +https://travis-ci.org/github/philmd/qemu/jobs/662357430 + +Guess is same unix path used: + +static SocketAddress unixaddr = { + .type = SOCKET_ADDRESS_TYPE_UNIX, + .u.q_unix.path = (char *)"test-char.sock", +}; + +Note, other tests in this file use g_dir_make_tmp(). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1868617 b/results/classifier/accel-gemma3:12b/vmm/1868617 new file mode 100644 index 000000000..a6251231a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1868617 @@ -0,0 +1,16 @@ + +multiseat: route different spice tablet events to distinct vdagents + +docs/multiseat.txt says: + +> Note on spice: Spice handles multihead just fine. But it can't do +> multiseat. For tablet events the event source is sent to the spice +> agent. But qemu can't figure it, so it can't do input routing. +> Fixing this needs a new or extended input interface between +> libspice-server and qemu. For keyboard events it is even worse: The +> event source isn't included in the spice protocol, so the wire +> protocol must be extended to support this. + +I'm not sure exactly what "can't figure it" means, but it looks to me like qemu can't route incoming tablet events from a spice client to distinct vdagent channels. + +I think this part of the process can be fixed within qemu. I've reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to address the issues with the keyboard interface at the protocol level. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1870039 b/results/classifier/accel-gemma3:12b/vmm/1870039 new file mode 100644 index 000000000..596702ce4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1870039 @@ -0,0 +1,34 @@ + +windows qemu-img fails to convert vhdx, assertion failure + +When attempting to convert Microsoft's 10X emulator image (19563) vhdx [1], qemu-img terminates abruptly with an assertion failure. (Newer versions of the vhdx exhibit the same issue.) + +Tested with qemu-img.exe --version +qemu-img version 4.2.50 (v4.2.0-676-g3a63b24a1b-dirty) + +Possibly related: 1719870 + +Partial Powershell cmdlet output: + +PS> Get-Vhd flash.vhdx + +VhdFormat : VHDX +VhdType : Dynamic +FileSize : 8365539328 +Size : 137438953472 +MinimumSize : 137438953472 +LogicalSectorSize : 4096 +PhysicalSectorSize : 4096 +BlockSize : 1048576 +ParentPath : +DiskIdentifier : 7BE7C459-AE5D-451A-9368-05875120F702 +FragmentationPercentage : 11 +Alignment : 1 +Attached : False +DiskNumber : +IsPMEMCompatible : False +AddressAbstractionType : None +Number : + + +[1] https://1drv.ms/u/s!AnjdAnZZcu-GpNFK_-tcNAq_4Aug8w?e=5JB6s0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1870098 b/results/classifier/accel-gemma3:12b/vmm/1870098 new file mode 100644 index 000000000..efe26bcc7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1870098 @@ -0,0 +1,13 @@ + +[block/vpc] dynamic disk header: off-by-one error for "num_bat_entries" + +In current qemu versions (observed in 5.0.0-rc1 as well as 2833ad487cfff7dc33703e4731b75facde1c561e), disk headers for dynamic VPCs are written with an incorrect "block allocation table entries" value. + +https://www.microsoft.com/en-us/download/details.aspx?id=23850 (the corresponding spec) states that: + +"Max Table Entries +This field holds the maximum entries present in the BAT. This should be equal to the number of blocks in the disk (that is, the disk size divided by the block size)." + +Inside the qemu code, the value is "disk size divided by the block size *plus one*". + +Calculating "num_bat_entries" as "total_sectors/(block_size / 512)" *should* fix the issue. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1871250 b/results/classifier/accel-gemma3:12b/vmm/1871250 new file mode 100644 index 000000000..6b999024f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1871250 @@ -0,0 +1,31 @@ + +Failed to create HAX VM + +Hi, + +I'm running the latest (master) of QEMU, though the version doesn't seem to matter - I also checked back to v4.2.0, exactly the same issue. And this isn't about the VM (guest), if I even just try to run, + +> "c:\Program Files\qemu\qemu-system-x86_64.exe" -accel hax + +Basically, just get a window to open, with acceleration enabled ... I get, +Open the vm device error:/dev/hax_vm/vm00, ec:3 +Failed to open vm 0 +Failed to create HAX VM +No accelerator found. + +But I checked - I have installed Intel HAXM, and verified it's running, +> sc query intelhaxm +SERVICE_NAME: intelhaxm + TYPE : 1 KERNEL_DRIVER + STATE : 4 RUNNING + (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) + WIN32_EXIT_CODE : 0 (0x0) + SERVICE_EXIT_CODE : 0 (0x0) + CHECKPOINT : 0x0 + WAIT_HINT : 0x0 + +Just remove the accelerator (-accel hax), and I get a window - so this is related to QEMU being able to contact / use the accelerator. + +Help!?!? + +Thanks! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1871267 b/results/classifier/accel-gemma3:12b/vmm/1871267 new file mode 100644 index 000000000..fa514b167 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1871267 @@ -0,0 +1,10 @@ + +Multiple (Repeating) Keystrokes in macOS + +Hi, + +I am finding this issue with v4.2.0, or the latest master - on a Windows host, with macOS guest. It happens using gtk (SPICE?) or VNC. When I get to a place to enter a keystroke, I quite reliably get multiple of the same key (i.e. press A, get AAAA). + +Thinking there may be a basic setting to address this? I did try it in Linux (kvm), no issue there. + +Thanks! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1871270 b/results/classifier/accel-gemma3:12b/vmm/1871270 new file mode 100644 index 000000000..9e556c3d0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1871270 @@ -0,0 +1,35 @@ + +[Feature Request] add usbredir device reset blacklist options support to allow macOS guest to iOS device usbredir + +Description of problem: +Currently, when a iOS device is redirected to a macOS VM, it falls into a reset-not-found loop. +Version-Release number of selected component (if applicable): +latest +How reproducible: +100% +Steps to Reproduce: + + +Connect an iOS device to Ubuntu 18.04.2 LTS (I believe it is the same for any distro.) + + +Connect virt-manager/virt-viewer to a macOS VM through SPICE (I am using OSX 10.15 Catalina) + + +Attempt to redirect the iOS device (iPad in my case) to the VM through usb redirection. + + +Actual results: +For any odd number of attempt, the guest macOS will send a reset to the iOS device which causes the host to reset the USB connection in the host side. In the UI, it will be displayed as a successful connection for a few seconds before it disconnects. After this, the iOS device will reconnect itself, but via a different device name /dev/bus/usb/x/y+1. +For any even number of attempt, when I select the iOS device in the virt-manager/virt-viewer UI, the connection will not success and instead a LIBUSB_ERROR_NOT_FOUND error will be provided. Then the UI will reload and get the new device name of the iOS device, falling into the behavior of the aforementioned odd number of attempt. +Expected results: +The macOS detects the iOS device and connects to it happily. +Additional info: +It seems that this bug has been first identified as in https://bugs.freedesktop.org/show_bug.cgi?id=100149, for a Samsung Android device, which the developers of SPICE applied a hotfix in https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirhost/usbredirhost.c#L147. However, there were no settings available for users to fix it. +A similar bug that also consists of a macOS guest/iOS device pair, but instead of being usbredir, is usb-host, has been identified and patched in https://github.com/qemu/qemu/commit/ba4c735b4fc74e309ce4b2551d258e442ef513a5, which is further modified into https://github.com/qemu/qemu/blame/146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8/hw/usb/host-libusb.c#L1486. Following such patch, I have attempted to apply such patch at host-side in https://github.com/michaellee8/qemu/blob/master/hw/usb/redirect.c (not correctly formatted currently, pls ignore it atm), however I discovered that this is not enough since it is also a SPICE issue, which resolves to virt-manager/virt-viewer. +This is probably a cross-project issue between qemu, spice (usbredir) and virt-manager/virt-viewer, which would some effort to coordinate a solution. However a working solution for this problem would probably benefits a lot of users whom relies on connecting a mobile device into a VM, for purposes like easier mobile development. Considering the report for the Samsung Android Device on a PC use case, such issue is probably cross-OS/cross-device. + +cross-references: +- https://bugzilla.redhat.com/show_bug.cgi?id=1821518 +- https://bugzilla.redhat.com/show_bug.cgi?id=1821517 +- https://gitlab.freedesktop.org/spice/usbredir/-/issues/10 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1872790 b/results/classifier/accel-gemma3:12b/vmm/1872790 new file mode 100644 index 000000000..9400b89ae --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1872790 @@ -0,0 +1,10 @@ + +empty qcow2 + +I plugged multiple qcow2 to a Windows guest. On the Windows disk manager all disks are listed perfectly, with their data, their real space, I even can explore all files on the Explorer, all cool + +On third party disk manager (all of them), I only have the C:\ HDD who act normally, all the other plugged qcow2 are seen as fully unallocated, so I can't manipulate them + +I want to move some partitions, create others, but on Windows disk manager I can't extend or create partition and on third party I didn't see the partitions at all + +Even guestfs doesn't recognize any partition table `libguestfs: error: inspect_os: /dev/sda: not a partitioned device` \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1872847 b/results/classifier/accel-gemma3:12b/vmm/1872847 new file mode 100644 index 000000000..0bd8ee0dc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1872847 @@ -0,0 +1,23 @@ + +qemu-alpha linux-user breaks python3.6 + +Running on Gentoo Linux in a chroot environment: +# python3 -c 'import selectors; selectors.DefaultSelector()' +Traceback (most recent call last): + File "<string>", line 1, in <module> + File "/usr/lib/python3.7/selectors.py", line 349, in __init__ + self._selector = self._selector_cls() +OSError: [Errno 22] Invalid argument + +However, on real hardware, with the same binaries there is no exception. + +This impacts whole python3 based Gentoo ebuild system (package management), and renders linux user mode alpha emulation in chroot environment building useless, more or less. + +The used systems: +# qemu-alpha --version +qemu-alpha version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +# uname -a +Linux blackbird 5.4.28-gentoo-blackbird-06 #2 SMP Sat Apr 4 13:13:10 CEST 2020 x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux +(chroot)# python3 --version +Python 3.7.7 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1874 b/results/classifier/accel-gemma3:12b/vmm/1874 new file mode 100644 index 000000000..3379347f6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1874 @@ -0,0 +1,18 @@ + +QGA：Whether arm windows VMS are supported？ +Description of problem: +Whether qga can be used within an arm windows virtual machine? + +Windows reports an error (Failed to pCatalog->InstallComponent.(Error: 80110401) Errors occurred accessing one or more objects - the ErrorInfo collection may have more detail) when I try to install msi. Windows reports a warning(Catalog Event ID 5488: Unable to load DLL qga-vss.dll) (Unable to validate DLL entry points) in Event Viewer. + +I get msi from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-qemu-ga/qemu-ga-win-105.0.2-1.el9/qemu-ga-x86_64.msi +Either gqa does not support ARM or this msi is only for X86 architecture? + + + + +Steps to reproduce: +1. Start arm windows 11 vm. +2. Install qemu guest agent. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1874486 b/results/classifier/accel-gemma3:12b/vmm/1874486 new file mode 100644 index 000000000..96484c3a2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1874486 @@ -0,0 +1,100 @@ + +Bug in qemu-img when converting to streamOptimized vmdk images + +I reviewed #1006655, and I think I'm already on a newer version, so this is either a regression or a new bug. + +I have been recently attempting to convert images from raw and qcow2 formats to vmdk. It appears that the option "subformat=streamOptimized" produces a broken or corrupted disk image. + +Current versions, running on Devuan testing: + +ii ipxe-qemu 1.0.0+git-20190125.36a4c85-1 all PXE boot firmware - ROM images for qemu +ii qemu 1:3.1+dfsg-8+deb10u4 amd64 fast processor emulator, dummy package +ii qemu-efi-aarch64 0~20181115.85588389-3 all UEFI firmware for 64-bit ARM virtual machines +ii qemu-efi-arm 0~20181115.85588389-3 all UEFI firmware for 32-bit ARM virtual machines +ii qemu-kvm 1:3.1+dfsg-8+deb10u4 amd64 QEMU Full virtualization on x86 hardware +ii qemu-slof 20180702+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:3.1+dfsg-8+deb10u4 all QEMU full system emulation (data files) +ii qemu-system-gui 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (user interface and audio support) +ii qemu-system-mips 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (miscellaneous) +ii qemu-system-ppc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:3.1+dfsg-8+deb10u4 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:3.1+dfsg-8+deb10u4 amd64 QEMU utilities + +Current uname -a: +Linux laptop-dev 5.4.0-0.bpo.3-amd64 #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07) x86_64 GNU/Linux + +Current CPU info: +$ cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 158 +model name : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz +stepping : 10 +microcode : 0xca +cpu MHz : 800.109 +cache size : 9216 KB +physical id : 0 +siblings : 12 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 4399.99 +clflush size : 64 +cache_alignment : 64 +address sizes : 39 bits physical, 48 bits virtual +power management: + +$ cat /proc/meminfo +MemTotal: 16098356 kB +MemFree: 2292720 kB +MemAvailable: 12323616 kB + + +Steps to reproduce: +1) Create a base o/s image in .qcow2 or raw format. I am using a Debian 10 (buster) image, and my images are created using packer 1.5.5. +2) Verify that the base image in .qcow2 format boots correctly in virt-manager when attached to a new VM. +3) Convert the image to vmdk using the following command: +qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,hwversion=6 <image name>.qcow2 <image name>.vmdk +4) Create a new VM using the newly-created .vmdk, being sure to make the storage adapter SCSI +Result: The image, on boot, will display many disk read errors. It will boot, but will start in read-only mode. + +This same image will also not boot correctly in ESXi or VirtualBox. In any of the three hypervisor environments, the bootloader menu (grub2) shows up correctly, but the machine will fail to boot correctly. + + +I reviewed the vmdk header, and the output is here: + +dd if=base.vmdk of=output-vm-disk1.descriptor bs=1 skip=512 count=1024 + +$ cat output-vm-disk1.descriptor +# Disk DescriptorFile +version=1 +CID=2120740c +parentCID=ffffffff +createType="streamOptimized" + +# Extent description +RW 61440000 SPARSE "base.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "6" +ddb.geometry.cylinders = "3824" +ddb.geometry.heads = "255" +ddb.geometry.sectors = "63" +ddb.adapterType = "lsilogic" + +Removing the "subformat=streamOptimized" argument from the qemu-img conversion command results in a working, albeit much larger image, with no disk read errors. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1874678 b/results/classifier/accel-gemma3:12b/vmm/1874678 new file mode 100644 index 000000000..f9d582694 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1874678 @@ -0,0 +1,4 @@ + +[Feature request] python-qemu package + +It would be useful to have the python/qemu/ files publish as a Python pip package, so users from distribution can also use the QEMU python methods (in particular for testing) without having to clone the full repository. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1874904 b/results/classifier/accel-gemma3:12b/vmm/1874904 new file mode 100644 index 000000000..95d87c83a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1874904 @@ -0,0 +1,12 @@ + +qemu windows with gtk and french keypad not working as expected + +When I use qemu on Windows 10 with a French AZERTY keypad with the correct options the emulated system keypad still QWERTY. If we use sdl it works fine the emulated keypad is AZERTY. + +Example of command with ubuntu live cd: +-> qemu-system-x86_64.exe -m 4G ubuntu-18.04.4-desktop-amd64.iso -display gtk -k fr + +NOTES: + - Using the same command on Linux works fine. The emulated keypad is AZERTY. + +Qemu version : 4.2.0 on Windows 10 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1875 b/results/classifier/accel-gemma3:12b/vmm/1875 new file mode 100644 index 000000000..cec7d8bf1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1875 @@ -0,0 +1,10 @@ + +qemu-system-x86_64: warning: no scancode found for keysym 65483 +Description of problem: +qemu-system-x86_64: warning: no scancode found for keysym 65483 + +I'm hoping this is something that could easily be added to qemu, rather than a limitation of windows: + +I want to bind F14 to an arbitrary key, in this case `keycode 148 = XF86Calculator`, but it's not happening, and qemu is giving the error: `qemu-system-x86_64: warning: no scancode found for keysym 65483` + +`xmodmap -e "keycode 148 = F14 F14 F14 F14 F14"` Executes with no error, and xev correctly shows as F14 pressed/released, but a windows 10 VM started afterwards cannot recognise this bind. diff --git a/results/classifier/accel-gemma3:12b/vmm/1877384 b/results/classifier/accel-gemma3:12b/vmm/1877384 new file mode 100644 index 000000000..89f187ff5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1877384 @@ -0,0 +1,26 @@ + +9pfs file create with mapped-xattr can fail on overlayfs + +QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do the same in master. +qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic "user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fs,mount_tag=fs -drive "file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" -append "$append" + + +I'm using CI that runs in a Docker container and runs a qemu VM with code and results shared via virtio 9p. +The 9p fsdev is configured with security_model=mapped-xattr +When the test code attempts to create a log file in an existing directory, open with O_CREAT fails with -ENOENT. + +The relevant strace excerpt is: + +28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20 +28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 21 +28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0 +28791 close(20) = 0 +28791 openat(21, "client.log", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20 +28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0 +28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 4, 0) = -1 ENOENT (No such file or directory) + +My hypothesis for what's going wrong is since the Docker container's overlayfs copies-up on writes, when it opens the file it's created a new version of the `src` directory containing a `client.log`, but this new src directory isn't accessible by file descriptor 20 and the lsetxattr call is instead attempting to set attributes on the path in the old `src` directory. + +Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and change `local_open2` to instead of calling `local_set_xattrat` to set the xattrs by directory file descriptor and file name, to have a version of local_set_xattrat` which uses `fsetxattr` to set the virtfs attributes instead of the `fsetxattrat_nofollow` helper. + +This reliably happened for me in CI, but I don't have access to the CI host or the time to strip the test down to make a minimal test case, and had difficulty reproducing the error on other machines. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1877716 b/results/classifier/accel-gemma3:12b/vmm/1877716 new file mode 100644 index 000000000..7fbba82e0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1878413 b/results/classifier/accel-gemma3:12b/vmm/1878413 new file mode 100644 index 000000000..18f372821 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1878413 @@ -0,0 +1,16 @@ + +/proc/sys/fs/binfmt_misc/ empty even though binfmt_misc is loaded + +_apksigner_ uses binfmt to execute via _jarwrapper_, since it is a JAR. We have a test suite that relies on _apksigner_ working. It was running fine in Ubuntu/bionic. Since it was pegged to LTS, it got upgraded to Ubuntu/focal and it stopped working. This is likely because /proc/sys/fs/binfmt_misc/ is totally empty. The "binfmt_misc" kernel module shows as loaded: + +$ grep binfmt /proc/modules +binfmt_misc 20480 1 - Live 0xffffffffc0452000 + +This relies on binfmt support in gitlab.com's CI runner setup, based on Docker. binfmt works in containers there, for example on Ubuntu/bionic: +https://gitlab.com/fdroid/fdroidserver/-/jobs/516857857 + +Something in Ubuntu/focal broke this when running focal in the container on the same Docker host runners: +https://gitlab.com/fdroid/fdroidserver/-/jobs/547148092 + +Debian's ci.debian.net lxc runners also have a similar problem, it might be related: +https://salsa.debian.org/ci-team/debian-ci-config/-/issues/1 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1878641 b/results/classifier/accel-gemma3:12b/vmm/1878641 new file mode 100644 index 000000000..03acab8ed --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1878641 @@ -0,0 +1,46 @@ + +Abort() in mch_update_pciexbar + +Hello, +I found an input which triggers an abort() in mch_update_pciexbar: + +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x000055555705c7ae in mch_update_pciexbar (mch=0x629000005920) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:324 +#3 0x000055555705bb6a in mch_write_config (d=0x629000005920, address=0x60, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:480 +#4 0x00005555570954fb in pci_host_config_write_common (pci_dev=0x629000005920, addr=0x60, limit=0x100, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:81 +#5 0x000055555709606e in pci_data_write (s=0x61d000096080, addr=0xf2000060, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:118 +#6 0x00005555570967d0 in pci_host_data_write (opaque=0x629000005200, addr=0x0, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:165 +#7 0x00005555564938b5 in memory_region_write_accessor (mr=0x629000005610, addr=0x0, value=0x7fffffff9c70, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#8 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffff9c70, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x629000005610, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#9 0x0000555556491df6 in memory_region_dispatch_write (mr=0x629000005610, addr=0x0, data=0x8400056e, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#10 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033b00, addr=0xcfc, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x0, l=0x4, mr=0x629000005610) at /home/alxndr/Development/qemu/exec.c:3137 +#11 0x00005555562bbad9 in flatview_write (fv=0x606000033b00, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#12 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#13 0x0000555556478c0a in cpu_outl (addr=0xcfc, val=0x8400056e) at /home/alxndr/Development/qemu/ioport.c:80 +#14 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ebf0) at /home/alxndr/Development/qemu/qtest.c:396 +#15 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#16 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", size=0xd2) at /home/alxndr/Development/qemu/qtest.c:722 +#17 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:183 +#18 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:195 +#19 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#20 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#21 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#23 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#24 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#25 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#26 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + + +I can reproduce this in qemu 5.0 built using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0xf2000060 +outl 0xcfc 0x8400056e +EOF + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1878915 b/results/classifier/accel-gemma3:12b/vmm/1878915 new file mode 100644 index 000000000..fbc9596e8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1878915 @@ -0,0 +1,40 @@ + +util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed. + +qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian) + +Stack trace: + + Stack trace of thread 31002: + #0 0x00000000b7faf1cd __kernel_vsyscall (linux-gate.so.1 + 0x11cd) + #1 0x00000000b6c618e2 __libc_signal_restore_set (libc.so.6 + 0x348e2) + #2 0x00000000b6c4a309 __GI_abort (libc.so.6 + 0x1d309) + #3 0x00000000b6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1) + #4 0x00000000b6c59929 __GI___assert_fail (libc.so.6 + 0x2c929) + #5 0x0000000000ba80be get_sqe (qemu-system-i386 + 0x6d00be) + #6 0x0000000000ba80cb add_poll_add_sqe (qemu-system-i386 + 0x6d00cb) + #7 0x0000000000ba820c fill_sq_ring (qemu-system-i386 + 0x6d020c) + #8 0x0000000000ba7145 aio_poll (qemu-system-i386 + 0x6cf145) + #9 0x0000000000aede63 blk_prw (qemu-system-i386 + 0x615e63) + #10 0x0000000000aeef95 blk_pread (qemu-system-i386 + 0x616f95) + #11 0x00000000008abbfa fdctrl_transfer_handler (qemu-system-i386 + 0x3d3bfa) + #12 0x0000000000906c3d i8257_channel_run (qemu-system-i386 + 0x42ec3d) + #13 0x00000000008ac119 fdctrl_start_transfer (qemu-system-i386 + 0x3d4119) + #14 0x00000000008ab233 fdctrl_write_data (qemu-system-i386 + 0x3d3233) + #15 0x0000000000708ae7 memory_region_write_accessor (qemu-system-i386 + 0x230ae7) + #16 0x00000000007059e1 access_with_adjusted_size (qemu-system-i386 + 0x22d9e1) + #17 0x000000000070b931 memory_region_dispatch_write (qemu-system-i386 + 0x233931) + #18 0x00000000006a87a2 address_space_stb (qemu-system-i386 + 0x1d07a2) + #19 0x0000000000829216 helper_outb (qemu-system-i386 + 0x351216) + #20 0x00000000b06d9fdc n/a (n/a + 0x0) + +Steps: + +0. qemu-img create -f raw fda.img 3840K +1. mformat -i fda.img -n 48 -t 80 -h 2 +2. qemu-system-i386 -fda fda.img -hda freedos.qcow2 +3. Attempt to run 'dosfsck a:' in the guest + +According to hw/block/fdc.c, a 3840K image should result in a virtual floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides. + +The assert seems bogus either way. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1879175 b/results/classifier/accel-gemma3:12b/vmm/1879175 new file mode 100644 index 000000000..56b3b5caa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1879175 @@ -0,0 +1,138 @@ + +GVTd not working (black screen) after upgrade to qemu-5.0.0 + +Hi QEMU team, + + +=== Problem Summary === + +I have recently upgraded from QEMU-3.1.0 to to QEMU-5.0.0 on Debian Unstable. Unfortunately GVTd (legacy passthrough of the integrated intel gpu) stopped working correctly. The guest can still see and loads the driver for the GPU, but the screen stays black. + +The following is the version used: + +$ /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 (Debian 1:5.0-5) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + + +=== Investigation/Triage done so far === + +Running QEMU with trace flags enabled shows the following behavior change for the same VM (left: 3.1.0, right: 5.0.0): + +vfio_realize (0000:00:02.0) group 1 vfio_realize (0000:00:02.0) group 1 +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f2bb1e00000] +vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f5d1d400000] | vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f2d7c800000] +vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f5d1d620000] | vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f2d84220000] +vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f5b41f00000] | vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f2bb1f00000] +vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff +vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff +vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f5d1d600000] | vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f2d84200000] +vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f5c01e00000] | vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f2c71e00000] +vfio_mdev (0000:00:02.0) is_mdev 0 vfio_mdev (0000:00:02.0) is_mdev 0 +vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 +vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s +vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 +vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 +vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 +vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 +vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 +vfio_populate_device_config Device 0000:00:02.0 config: vfio_populate_device_config Device 0000:00:02.0 config: + 0x1000, offset: 0x70000000000, flags: 0x3 0x1000, offset: 0x70000000000, flags: 0x3 +vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] +vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] +vfio_check_pm_reset 0000:00:02.0 Supports PM reset vfio_check_pm_reset 0000:00:02.0 Supports PM reset +vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac +vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 11, 80008086/38 < +vfio_listener_region_del region_del 0x0 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0x9ffff [0x7f5b41e00000] < +vfio_listener_region_add_skip SKIPPING region_add 0xa0000 - 0xbffff < +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < +vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) + 0x100, offset: 0x70000000000, flags: 0x3 0x100, offset: 0x70000000000, flags: 0x3 +vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument +vfio_pci_reset (0000:00:02.0) vfio_pci_reset (0000:00:02.0) +vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 +vfio_intx_disable (0000:00:02.0) vfio_intx_disable (0000:00:02.0) +vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) +vfio_listener_region_del region_del 0x0 - 0x9ffff < +vfio_listener_region_del_skip SKIPPING region_del 0xa0000 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] < +vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) +vfio_listener_region_del region_del 0x0 - 0xbffff vfio_listener_region_del region_del 0x0 - 0xbffff +vfio_listener_region_del region_del 0xc0000 - 0xdffff vfio_listener_region_del region_del 0xc0000 - 0xdffff +vfio_listener_region_del region_del 0xe0000 - 0xfffff vfio_listener_region_del region_del 0xe0000 - 0xfffff +vfio_listener_region_del region_del 0x100000 - 0xbfffffff vfio_listener_region_del region_del 0x100000 - 0xbfffffff +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f2bb1e00000] + +We can see here, the following key lines are not printed in 5.0.0: + +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < + +Looking through the code and bisecting the problem (I can provide more detail if helpful), shows the following ifdef statement lines introduce the problem: + +https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253 + + 1246 void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr) + 1247 { + 1248 vfio_probe_ati_bar4_quirk(vdev, nr); + 1249 vfio_probe_ati_bar2_quirk(vdev, nr); + 1250 vfio_probe_nvidia_bar5_quirk(vdev, nr); + 1251 vfio_probe_nvidia_bar0_quirk(vdev, nr); + 1252 vfio_probe_rtl8168_bar2_quirk(vdev, nr); + 1253 #ifdef CONFIG_VFIO_IGD + 1254 vfio_probe_igd_bar4_quirk(vdev, nr); + 1255 #endif + 1256 } + +This was added by the following commits: + +https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19#diff-38093e21794c7a4987feb71e498dbdc6 + +Reading through the commit message, I suspect the something may be happening with the Kconfig switches mentioned there. + + + +=== Validation/Workaround === + +I have rebuilt the package with the following two changes: + +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c +0a1 +> #define CONFIG_VFIO_IGD y +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig +42c42 +< default y if PC_PCI +--- +> default y +root@debian:/home/test/src# + +GVTd started working fine again (Screen shows output again). + +I have tried with either change alone: + +- with only the ifdef in pci-quirks.c compilation fails with linker errors +- with only the Kconfig it compiles, but GVTd still does not work (black screen) + + + +Please take a look and thank you very much for a fantastic product! + +TheCatFelix \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1879587 b/results/classifier/accel-gemma3:12b/vmm/1879587 new file mode 100644 index 000000000..05b82f8ad --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1879587 @@ -0,0 +1,21 @@ + +Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 + +I am running into a situation where I have: +- A hypervisor running in EL2, AA64 +- A guest running in EL1, AA32 + +We trap certain accesses to special registers such as DACR (via HCR.TVM). One instruction that is trapped is: + +ee03ef10 -> mcr 15, 0, lr, cr3, cr0, {0} + +The guest is running in SVC mode. So, LR should refer to LR_svc there. LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However, the actual ESR value is: 0xfe00dc0 + +If we decode the 'rt': +>>> (0xfe00dc0 >> 5) & 0x1f +14 + +My understanding is that 14 is incorrect in the context of AA64. rt should be set to 18. The current mode being SVC, LR refers to LR_svc not LR_usr. In other words, the mapping between registers in AA64 and AA32 doesn't seem to be accounted for. I've tested this with Qemu 5.0.0 + +Let me know if that makes sense and if you would like more info. I am also happy to test patches. +Thanks for all the great work on Qemu! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1879672 b/results/classifier/accel-gemma3:12b/vmm/1879672 new file mode 100644 index 000000000..2877d208d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1879672 @@ -0,0 +1,13 @@ + +QEMU installer with WHPX support + +People often ask the community to add WHPX support to the QEMU installer for Windows, +but it is impossible due to the license limitations of the WHPX SDK. + +The WinHvEmulation.h and WinHvPlatform.h header files needed are "All +rights reserved". + +However these headers only contain struct definitions and integer constants, +no functional code in macros or inline functions. See: +https://<email address hidden>/msg645815.html +It is questionable whether the headers alone can be considered copyrightable material. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1879998 b/results/classifier/accel-gemma3:12b/vmm/1879998 new file mode 100644 index 000000000..827b46909 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1879998 @@ -0,0 +1,28 @@ + +Bad check for return value of mmap() + +In +./roms/skiboot/extract-gcov.c +there is this code: + + addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); + assert(addr != NULL); + +This check is wrong, mmap never returns NULL, on errors it returns MAP_FAILED (or -1). (Also sidenote: asserts usually shouldn't be used for error checking.) + +In +roms/skiboot/libstb/print-container.c +there's a similar issue: + + payload = mmap(NULL, payload_st.st_size - SECURE_BOOT_HEADERS_SIZE, + PROT_READ, MAP_PRIVATE, fdin, SECURE_BOOT_HEADERS_SIZE); + if (!payload) + +This if should be (payload == MAP_FAILED). + +Another one is in +./roms/skiboot/libstb/create-container.c + +And in +./roms/u-boot/tools/aisimage.c +there's an mmap call that does not check the return value at all. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1880066 b/results/classifier/accel-gemma3:12b/vmm/1880066 new file mode 100644 index 000000000..9eeef9c31 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1880066 @@ -0,0 +1,70 @@ + +Microphone input dies in guest when switching evdev input + +justin@justin-3900x:~$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal + + + +justin@justin-3900x:~$ apt list --installed | egrep '*qemu*|*kvm*' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +ipxe-qemu-256k-compat-efi-roms/focal,focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/focal,focal,now 1.0.0+git-20190109.133f4c4-0ubuntu3 all [installed,automatic] +libvirt-daemon-driver-qemu/focal,now 6.0.0-0ubuntu8 amd64 [installed,automatic] +qemu-block-extra/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-kvm/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +qemu-system-common/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-system-data/focal-updates,focal-updates,focal-security,focal-security,now 1:4.2-3ubuntu6.1 all [installed,automatic] +qemu-system-gui/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-system-x86/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +qemu-utils/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +justin@justin-3900x:~$ + +This did not happen in Eoan (qemu 4.0.0). I was able to switch in/out of a VM with my audio coming through fine. I enabled Eoan in my sources.list, downgraded all my qemu packages, and the issue was resolved. + +This happens on the latest Windows 10 guest when a sound device is listening for the microphone. + +/var/log/libvirt/qemu/<vmname>.log spews this error out when I switch with evdev (which is just the keyboard and mouse, the audio is passed through I assume spice): + + +audio: live=228193 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=228675 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=228675 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=229156 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=229156 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=229638 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=229638 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=230119 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=230119 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=230600 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=230600 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=231081 sw->hw->conv_buf->size=1920 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1880507 b/results/classifier/accel-gemma3:12b/vmm/1880507 new file mode 100644 index 000000000..bfbcb5aea --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1880507 @@ -0,0 +1,4 @@ + +VMM from Ubuntu 20.04 does not show the memory consumption + +KVM host system: Ubuntu 18.04 and 20.04, guest machines: Windows and Ubuntu. Management through Ubuntu 20.04, vmm does not show RAM consumption for Windows guest systems (Win7, Win2008R2), for Ubuntu values are shown. The error is not observed in Ubuntu 18.04/vmm. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1881231 b/results/classifier/accel-gemma3:12b/vmm/1881231 new file mode 100644 index 000000000..ba97c8a94 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1881231 @@ -0,0 +1,32 @@ + +colo: Can not recover colo after svm failover twice + +Hi Expert, +x-blockdev-change met some error, during testing colo + +Host os: +CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm and remove the nbd child from the quorum to wait for recover + type those commands on primary vm console: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} +3. recover colo +4. kill secondary vm again after recover colo and type same commands as step 2: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} + but the first command got error + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} +{"error": {"class": "GenericError", "desc": "Node 'colo-disk0' does not have child 'children.1'"}} + +according to https://www.qemu.org/docs/master/qemu-qmp-ref.html +Command: x-blockdev-change +Dynamically reconfigure the block driver state graph. It can be used to add, remove, insert or replace a graph node. Currently only the Quorum driver implements this feature to add or remove its child. This is useful to fix a broken quorum child. + +It seems x-blockdev-change not worked as expected. + +Thanks. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1881552 b/results/classifier/accel-gemma3:12b/vmm/1881552 new file mode 100644 index 000000000..6c9478b9a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1881552 @@ -0,0 +1,54 @@ + +potential AArch64 ABI bug wrt handling of 128-bit bit-fields + +After upgrading to Ubuntu 20.04 LTS, GCC 9.3 displays a lot of notes: + +hw/block/pflash_cfi01.c: In function ‘pflash_mem_read_with_attrs’: +hw/block/pflash_cfi01.c:663:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 663 | static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, uint64_t *value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/block/pflash_cfi01.c: In function ‘pflash_mem_write_with_attrs’: +hw/block/pflash_cfi01.c:677:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 677 | static MemTxResult pflash_mem_write_with_attrs(void *opaque, hwaddr addr, uint64_t value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_mem_valid’: +hw/nvram/fw_cfg.c:475:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 475 | static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_data_mem_valid’: +hw/nvram/fw_cfg.c:483:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 483 | static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_ctl_mem_valid’: +hw/nvram/fw_cfg.c:501:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 501 | static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_comb_valid’: +hw/nvram/fw_cfg.c:521:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 521 | static bool fw_cfg_comb_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_do_hyp_read’: +hw/intc/arm_gic.c:1996:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1996 | static MemTxResult gic_do_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_thiscpu_hyp_read’: +hw/intc/arm_gic.c:1979:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1979 | static MemTxResult gic_thiscpu_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_get_current_pending_irq’: +hw/intc/arm_gic.c:419:17: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 419 | static uint16_t gic_get_current_pending_irq(GICState *s, int cpu, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This seems related to: +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 +https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=c590597c45 + + This is pretty unlikely in real code, but similar to Arm, the AArch64 + ABI has a bug with the handling of 128-bit bit-fields, where if the + bit-field dominates the overall alignment the back-end code may end up + passing the argument correctly. This is a regression that started in + gcc-6 when the ABI support code was updated to support overaligned + types. The fix is very similar in concept to the Arm fix. 128-bit + bit-fields are fortunately extremely rare, so I'd be very surprised if + anyone has been bitten by this. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1881648 b/results/classifier/accel-gemma3:12b/vmm/1881648 new file mode 100644 index 000000000..ff7422621 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1881648 @@ -0,0 +1,18 @@ + +`qemu-img info` reports an incorrect actual-size when the underlying posix filesystem has transparent compression + +qemu-img info reports the same thing as `du`*1024: + +$ qemu-img info --output json ./my.qcow2 | jq '."actual-size"' +558619648 + +$ du ./my.qcow2 +545527 ./my.qcow2 + +$ echo $((558619648 / 545527)) +1024 + +and this is correct in terms of bytes on disk, but due to transparent compression implemented by the filesystem, it is not the actual byte count: + +$ du -h --apparent-size ./my.qcow2 +1346568192 my.qcow2 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1882787 b/results/classifier/accel-gemma3:12b/vmm/1882787 new file mode 100644 index 000000000..7310ae0eb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1882787 @@ -0,0 +1,59 @@ + +AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut + +There was a change in https://github.com/qemu/qemu/commit/571a8c522e0095239598347ac0add93337c1e0bf#diff-230ab01fa7fb1668a1e9183241115cb0R1852-R1853 (audio/audio.c) which breaks audio output on devices which have multiple software voices on the same hardware voice. + +When multiple software voices use the same hardware voice, then setting a volume / mute for any of the software voices, will affect all other software voices, too. + +I'm not sure if such a use-case exists in QEMU; however, it does exist in my fork. +It's also easy to see that this is a bug in the QEMU audio subsystem. + +The API (and broken function) for this is: + +``` + void AUD_set_volume_out (SWVoiceOut *sw, int mute, uint8_t lvol, uint8_t rvol) +``` + +So this is supposed to modify the SWVoiceOut. + +However, if the backend supports `pcm_ops->volume_out` this does not work as expected. It's always as if you had called: + +``` + void AUD_set_volume_out (HWVoiceOut *hw, int mute, uint8_t lvol, uint8_t rvol) +``` + +*(Note how this modifies the hardware voice)* + + +In my specific use case, I have 2 outputs (digital and analog audio on AC97), and I want to mute the digital audio output, but I still need to keep the voice activated for timing. +However, if I mute the digital audio SWVoiceOut, it will also affect the other SWVoiceOut (for analog audio) on the same HWVoiceOut. + +--- + +Old code - if the hardware supports volume changes, it will receive the software voice which should be modified, so changes can be restricted to that one voice: + +``` + HWVoiceOut *hw = sw->hw; + [...] + if (hw->pcm_ops->ctl_out) { + hw->pcm_ops->ctl_out (hw, VOICE_VOLUME, sw); + } +``` + +New code - the hardware backend will have no way to differentiate software voices; so any change will affect all voices. The volume which was set last on any sw voice will set a global volume / mute for all voices on the hardware backend: + +``` + HWVoiceOut *hw = sw->hw; + [...] + if (hw->pcm_ops->volume_out) { + hw->pcm_ops->volume_out(hw, &sw->vol); + } +``` + +The old interface was already broken with some (all?) backends, because they ignored the software voice, but at least the design made sense. +However, the new design is fundamentally broken because it doesn't even tell the backend which voice is supposed to be modified. + +--- + +Bug was introduced in cecc1e79bf9ad9a0e2d3ce513d4f71792a0985f6 +The affected code was touched since then, but still remains in 49ee11555262a256afec592dfed7c5902d5eefd2 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1882817 b/results/classifier/accel-gemma3:12b/vmm/1882817 new file mode 100644 index 000000000..e7c6357d5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1882817 @@ -0,0 +1,26 @@ + +Segfault in audio_pcm_sw_write with audio over VNC + +QEMU 5.0.0, built with ./configure --target-list=x86_64-softmmu --enable-debug --disable-strip --disable-docs --disable-sdl + +Running on a headless host (Ryzen 3600), Arch Linux, 64bit latest. +Guest is also Arch Linux, 64bit. + +Started with qemu-system-x86_64 -vnc 0.0.0.0:0 -enable-kvm -m 4096 -cpu host -smp cores=2,threads=1,sockets=1 -machine q35 -vga std -device + ich9-ahci,id=ahci -drive file=vm0.qcow2,format=qcow2,if=none,id=dsk0 -device ide-hd,drive=dsk0,bus=ahci.0 -soundhw hda + +So, a headless VM is running on a server and is being connected to over VNC. The virtual sound card is detected and speaker test is running inside the VM. So far so good. + +Then, i tell the VNC client to enable audio (QEMU Audio Client Message, 255,1,0). QEMU responds with a "stream is about to start" message (QEMU Audio Server Message, 255,1,1) and then promptly crashes without sending anything else. + +Running it in GDB produces a crash at audio/audio.c:739 + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +audio_pcm_sw_write (sw=0x5555575bbf30, buf=0x0, size=1628) at audio/audio.c:739 +739 if (!sw->hw->pcm_ops->volume_out) { + +The exact sequence of events does not matter - i can enable sound before playing anything, and then it would say nothing and keep working, but crash with the same message once anything sound-playing is launched in the VM. + +Using different soundhw or adding various audiodev options does not seem to affect anything. + +I can't quite figure out if the QEMU Audio VNC extension is supposed to work at all or not, but it would be handy to me if it is. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1883414 b/results/classifier/accel-gemma3:12b/vmm/1883414 new file mode 100644 index 000000000..9a801858d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1883414 @@ -0,0 +1,28 @@ + +Cannot build qemu-5.0.0 from tarball + +Cannot build qemu 5.0.0 from the release tarball. Building from git-clone succeeds. + +After downloading and unpacking the 5.0.0 tarball, I typed the following: + +mkdir build +cd build +../configure + +Then got the following error message: + +ERROR: missing file /home/uri/qemu-5.0.0/ui/keycodemapdb/README + +This is not a GIT checkout but module content appears to +be missing. Do not use 'git archive' or GitHub download links +to acquire QEMU source archives. Non-GIT builds are only +supported with source archives linked from: + + https://www.qemu.org/download/#source + +Developers working with GIT can use scripts/archive-source.sh +if they need to create valid source archives. + +It appears the ui/keycodemapdb is missing some files that are obtained from a git submodule in a git tree. + +Building from a git clone succeeds. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1885247 b/results/classifier/accel-gemma3:12b/vmm/1885247 new file mode 100644 index 000000000..4565d6dc0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1885247 @@ -0,0 +1,22 @@ + +Build error in Intel 32-bit hosts + +The code base is on master, checked out on Thursday June25th 2020, 0250c595c9d. The build procedure: + +$ mkdir build-gcc +$ cd build-gcc +$ ../configure +$ make + +The build error message is: + + CC x86_64-softmmu/hw/hyperv/hyperv.o + CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o + CC x86_64-softmmu/hw/hyperv/vmbus.o +/home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’: +/home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); + ^ +cc1: all warnings being treated as errors +make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] Error 1 +make: *** [Makefile:527: x86_64-softmmu/all] Error 2 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1885720 b/results/classifier/accel-gemma3:12b/vmm/1885720 new file mode 100644 index 000000000..56fe79e7a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1885720 @@ -0,0 +1,12 @@ + +qemu/migration/postcopy-ram.c:387: bad return expression ? + +qemu/migration/postcopy-ram.c:387:9: style: Non-boolean value returned from function returning bool [returnNonBoolInBooleanFunction] + +Source code is + + return -1; + +but + +bool postcopy_ram_supported_by_host( \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1886225 b/results/classifier/accel-gemma3:12b/vmm/1886225 new file mode 100644 index 000000000..0fc5285c7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1886225 @@ -0,0 +1,17 @@ + +[Feature request] Oracle Solaris 11.4 VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +Some people have interest in building QEMU on Solaris: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01429.html + +To help them it would be useful to have a Solaris VM. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1886285 b/results/classifier/accel-gemma3:12b/vmm/1886285 new file mode 100644 index 000000000..1f44d3efb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1886285 @@ -0,0 +1,10 @@ + +Provide SMB option to support Windows 2000 + +As of SAMBA 4.11 (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is disabled by default (and may be removed in the future). This breaks SMB shares with Windows 2000 guests. + +Adding the following line to smb.conf fixes this: + +min protocol = NT1 + +I would propose that an option be added to add this line to smb.conf to support these legacy operating systems. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1887 b/results/classifier/accel-gemma3:12b/vmm/1887 new file mode 100644 index 000000000..01dfec3df --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1887 @@ -0,0 +1,10 @@ + +Window VM failed to resume when using GPU passthrough(GVT-d) on Intel platform if add 'hv-stimer' option, seems like it happened after V6.2.0 +Description of problem: +Windows VM failed to be resumed if adding 'hv-stimer' after Qemu v6.2.0. +Steps to reproduce: +1.Set up GVTd env and launch Windows 10 VM as guest; +2. Sleep the Windows VM with Sleep button; +3. Resume Windows VM via telnet to qemu ,e.g.,'telnet 127.0.0.1 2222', then input 'system_wakeup' to resume Windows VM. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1887604 b/results/classifier/accel-gemma3:12b/vmm/1887604 new file mode 100644 index 000000000..56bfe8fb3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1887604 @@ -0,0 +1,29 @@ + +Forward host UNIX socket to guest TCP port + +Hello. I've been racking my brain trying to work out if this is possible. + +I would like to be able to forward to a guest TCP port, via a host UNIX socket to avoid opening a TCP port on the host. For example: + +qemu-system-i386 [...] -nic user,hostfwd=unix:/path/to/socket-:22 + +and then connect to the VM like: + +ssh -o "ProxyCommand socat - unix-connect:/path/to/socket" user@0.0.0.0 + +QEMU, as versatile as it is, doesn't appreciate my intuited syntax "hostfwd=unix:...". It is also unhappy with: + +qemu-system-i386 [...] \ + -chardev socket,id=foo,path=/path/to/socket,server,nowait \ + -nic user,hostfwd=chardev:foo-:22 + +And: + +qemu-system-i386 [...] \ + -nic user \ + -chardev socket,id=foo,path=/path/to/socket,server,nowait \ + -chardev socket,id=foo,host=10.0.2.15,port=22 + +I already found out how to connect in the opposite direction, **from** guest TCP to host UNIX, via guestfwd -> cmd -> socat. So I feel like there ought to be a way. + +If this is not yet a feature I would like to request it, and if it is, please tell me how! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1888467 b/results/classifier/accel-gemma3:12b/vmm/1888467 new file mode 100644 index 000000000..5dbefd015 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1888467 @@ -0,0 +1,13 @@ + +qemu-img http convert bug + +Hello, Why the file sizes of http conversion and local conversion are inconsistent? + +Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。 +My image size is 40 G, raw format. + +The source is the same file, but the access method is different +http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx xxx.vdi（19G，after conversion） +local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw xxx.vdi（3G，after conversion） + +thank you \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1888818 b/results/classifier/accel-gemma3:12b/vmm/1888818 new file mode 100644 index 000000000..c79c7245c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1888818 @@ -0,0 +1,50 @@ + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 + +Test Environment: +DPDK version: DPDK v20.08 +Other software versions: qemu4.2, qemu5.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 8.4.0 +Hardware platform: Purley. +Test Setup +Steps to reproduce +List the steps to reproduce the issue. + +Test flow +========= +1. Launch vhost-user testpmd as port0 with 2 queues: + +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 +testpmd>start + +3. Launch qemu with virtio-net: + + taskset -c 13 \ + qemu-system-x86_64 -name us-vhost-vm1 \ + -cpu host -enable-kvm -m 2048 -object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem \ + -mem-prealloc -monitor unix:/tmp/vm2_monitor.sock,server,nowait -netdev user,id=yinan,hostfwd=tcp:127.0.0.1:6005-:22 -device e1000,netdev=yinan \ + -smp cores=1,sockets=1 -drive file=/home/osimg/ubuntu16.img \ + -chardev socket,id=char0,path=./vhost-net,server \ + -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce,queues=2 \ + -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=mynet1,mrg_rxbuf=on,csum=on,gso=on,host_tso4=on,guest_tso4=on,mq=on,vectors=15 \ + -vnc :10 -daemonize + +6. Quit testpmd and restart vhost-user : + +testpmd>quit +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 + + +Expected Result: +After the vhost-user is killed then re-launched, the virtio-net can connect back to vhost-user again. + +Actual Result: +Vhost-user relaunch failed with continous log printed"VHOST_CONFIG: Processing VHOST_USER_SET_FEATURES failed. + +Analysis: +This is a regression bug, bad commit: c6beefd674f +When vhost-user quits, QEMU doesnot save acked features for each virtio-net after vhost-user quits. When vhost-user reconnects to QEMU, QEMU sends two different features(one is the true acked feature while the another is 0x40000000) to vhost-user successively which causing vhost-user exits abnormally. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1888964 b/results/classifier/accel-gemma3:12b/vmm/1888964 new file mode 100644 index 000000000..9ce17f20d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1888964 @@ -0,0 +1,41 @@ + +Segfault using GTK display with dmabuf (iGVT-g) on Wayland + +When using... + a) Intel virtualized graphics (iGVT-g) with dmabuf output + b) QEMU's GTK display with GL output enabled (-display gtk,gl=on) + c) A Wayland compositor (Sway in my case) +a segfault occurs at some point on boot (I guess as soon as the guest starts using the virtual graphics card?) + +The origin is the function dpy_gl_scanout_dmabuf in ui/console.c, where it calls + con->gl->ops->dpy_gl_scanout_dmabuf(con->gl, dmabuf); +However, the ops field (struct DisplayChangeListenerOps) does not have dpy_gl_scanout_dmabuf set because it is set to dcl_gl_area_ops which does not have dpy_gl_scanout_dmabuf set. +Only dcl_egl_ops has dpy_gl_scanout_dmabuf set. +Currently, the GTK display uses EGL on X11 displays, but GtkGLArea on Wayland. This can be observed in early_gtk_display_init() in ui/gtk.c, where it says (simplified code): + +if (opts->has_gl && opts->gl != DISPLAYGL_MODE_OFF) { + if (GDK_IS_WAYLAND_DISPLAY(gdk_display_get_default())) { + gtk_use_gl_area = true; + gtk_gl_area_init(); + } else { + DisplayGLMode mode = opts->has_gl ? opts->gl : DISPLAYGL_MODE_ON; + gtk_egl_init(mode); + } +} + +To reproduce the findings above, add this assertion to dpy_gl_scanout_dmabuf: + assert(con->gl->ops->dpy_gl_scanout_dmabuf); +This will make the segfault turn into an assertion failure. + +A workaround is to force QEMU to use GDK's X11 backend (using GDK_BACKEND=x11). + +Note: This might be a duplicate of 1775011, however the information provided in that bug report is not sufficient to make the assertion. + +QEMU version: b0ce3f021e0157e9a5ab836cb162c48caac132e1 (from Git master branch) +OS: Arch Linux, Kernel Version 5.17.0-1 + +Relevant flags of the QEMU invocation: +qemu-system-x86_64 \ + -vga none \ + -device vfio-pci-nohotplug,sysfsdev="$GVT_DEV",romfile="${ROMFILE}",display=on,x-igd-opregion=on,ramfb=on \ + -display gtk,gl=on \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1889 b/results/classifier/accel-gemma3:12b/vmm/1889 new file mode 100644 index 000000000..2095036d8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1889 @@ -0,0 +1,48 @@ + +IO delays on live migration lv initialization +Description of problem: +Hi, + +When I live migrate a VM via Proxmox and the destination is an LVM thin pool I see that at the start of copying the disk it's first initialized. + +This leads the thin volume to be directly 100% allocated which needs to be discarded afterwards. Not ideal but .... + +The more annoying thing is that this initialization step used 100% of disk IO. In iotop I see it writing over 1000MB/sec. The nasty side effect is that other VM's on that host are negatively affected. It's not completely locked up, I can ssh in and look around, but storage intensive things see more delay. With e.g. http requests timing out. And even a simple ls command could take 10+ seconds which is normally instant. + + +I've previously reported it on the [proxmox forum](https://forum.proxmox.com/threads/io-delays-on-live-migration-lv-initialization.132296/#post-582050) but the call was made that this is behavior from Qemu. + +> The zeroing happens, because of what QEMU does when the discard option is enabled: + + +When I disable discard for the VM disk I can see that it's not pre-initialized during migration, but not having that defeats the purpose of having an lvm thin pool. + +For the (disk) migration itself I can set a bandwidth limit ... could we do something similar for initialization? + + +Even better would be to not initialize at all when using LVM thin. As far as I understand it the new blocks allocated by lvm thin should always be empty. +Steps to reproduce: +1. Migrate a vm with a large disk +2. look in iotop on the new host, would be see more write IO then the network could handle.. just before the disk content is transferred. +3. look in another VM on the destination host, reading from disk would be significantly slower then normal. +Additional information: +An example VM config +``` +agent: 1,fstrim_cloned_disks=1 +balloon: 512 +bootdisk: scsi0 +cores: 6 +ide2: none,media=cdrom +memory: 8196 +name: ... +net0: virtio=...,bridge=... +numa: 0 +onboot: 1 +ostype: l26 +scsi0: thin_pool_hwraid:vm-301-disk-0,discard=on,format=raw,size=16192M +scsi1: thin_pool_hwraid:vm-301-disk-1,discard=on,format=raw,size=26G +scsihw: virtio-scsi-pci +serial0: socket +smbios1: uuid=... +sockets: 1 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1889943 b/results/classifier/accel-gemma3:12b/vmm/1889943 new file mode 100644 index 000000000..84e4f284e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1889943 @@ -0,0 +1,48 @@ + +Improper TCP/IP packet splitting on e1000e/vmxnet3 + +Problem Description: +When using a tap interface and the guest sends a TCP packet that would need to be segmented, it is fragmented using IP fragmentation. The host does not reassemble the IP fragments and forwards them to the next hop. This causes issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios). +This issue occurs on the e1000e and vmxnet3 NIC models, and possibly others. It does not occur on the virtio(which passes the entire packet through to the host w/o fragmentation or segmentation) or the e1000 model(). + +Test scenario: +Setup a tap and network bridge using the directions here: https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c +Boot the machine into any modern guest(a Fedora 31 live iso was used for testing) +Begin a wireshark capture on the host machine +On the host(or another machine on the network) run: npx http-echo-server(See https://github.com/watson/http-echo-server) +On the guest run +Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta ut. Phasellus at quam bibendum, fermentum libero sit amet, ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus ligula, hendrerit nec aliquam non, finibus a turpis. Proin scelerisque convallis ante, et pharetra elit. Donec nunc nisl, viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis neque posuere placerat quis quis massa. Donec quis lacus ligula. Donec mollis vel nisi eget elementum. Nam id magna porta nunc consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor mattis. Praesent in mattis tortor. In venenatis convallis quam, in posuere nibh. Proin non dignissim massa. Cras at mi ut lorem tristique fringilla. Nulla ac quam condimentum metus tincidunt vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus condimentum, arcu sem molestie augue, in suscipit mauris odio mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan urna maximus. Nam nec odio volutpat, varius est id, tempus libero. Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. Etiam tempor, est sit amet vulputate molestie, urna neque sodales leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor dapibus maximus faucibus ut erat. Ut pharetra tempor massa in bibendum. Interdum et malesuada fames ac ante ipsum primis in faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet volutpat egestas, est est pulvinar erat, sed luctus nisl ligula eget justo vestibulum.” <ECHOSERVERIP:PORT> + +2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/ + +Compare results from an e1000, a virtio, and a e1000e card: ++--------+-----------+---------+------------+ +| Model | Fragment | Segment | Wire Size | ++--------+-----------+---------+------------+ +| e1000e | Yes | NO | 1484 + 621 | ++--------+-----------+---------+------------+ +| e1000 | No | Yes | 1516 + 620 | ++--------+-----------+---------+------------+ +| Virtio | NO | NO | 2068 | ++--------+-----------+---------+------------+ + +Expected Results: +TCP Segment to proper size OR pass full size to host and let the host split if necessary. + +Configuration changes that did not work: +Disable host, guest, router firewalls +Different Hosts +Different Physical NICs +Libvirt based NAT/Routed modes +Fedora 32 vs 31 +Qemu 4.2.0 vs github commit d74824cf7c8b352f9045e949dc636c7207a41eee + +System Information: +lsb_release -rd +Description: Fedora release 32 (Thirty Two) +Release: 32 + +uname -a +Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I can provide additional logs, debug info, etc. if needed. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1890208 b/results/classifier/accel-gemma3:12b/vmm/1890208 new file mode 100644 index 000000000..1ec9c5f7a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1890208 @@ -0,0 +1,12 @@ + +Mouse pointer disappears when it is over console window + +The host mouse pointer disappears when it is over a console window. + +I am emulating quite simple hardware: just text console and no mouse. I don't expect the mouse to have any effect on the emulated computers, but I need to know where the mouse pointer is. That is important because I need to use the mouse to switch between applications and to switch between virtual machines (QEMU grabs Alt+Tab events). Also, it is quite tricky to work with multiple screens when we don't know where the mouse pointer is. + +I am using: +* Virtual Machine Manager 2.2.1 +* QEMU 4.2.0 +* Fedora 32 +* KDE Plasma 5.18.5 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1890395 b/results/classifier/accel-gemma3:12b/vmm/1890395 new file mode 100644 index 000000000..5cfd7449e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1890395 @@ -0,0 +1,137 @@ + +qmp/hmp: crash if client closes socket too early + +Qemu crashes on qmp/hmp command if client closes connection before reading the whole response from the socket. + +Reproducer: + +1. Start arbitrary vm via qemu +2. Send e.g. hmp command 'info mem' +3. Abort before whole response came back + + +Stack Trace: + +Stack trace of thread 6493: +#0 0x0000559902fd2d30 object_get_class (qemu-system-x86_64) +#1 0x0000559903071020 qio_channel_create_watch (qemu-system-x86_64) +#2 0x000055990305f437 qemu_chr_fe_add_watch (qemu-system-x86_64) +#3 0x0000559902f7340d monitor_flush_locked (qemu-system-x86_64) +#4 0x0000559902f7360e monitor_flush_locked (qemu-system-x86_64) +#5 0x0000559902f74342 qmp_send_response (qemu-system-x86_64) +#6 0x0000559902f74409 monitor_qmp_respond (qemu-system-x86_64) +#7 0x0000559902f74bc0 monitor_qmp_bh_dispatcher (qemu-system-x86_64) +#8 0x00005599030c37be aio_bh_call (qemu-system-x86_64) +#9 0x00005599030c6dd0 aio_dispatch (qemu-system-x86_64) +#10 0x00005599030c369e aio_ctx_dispatch (qemu-system-x86_64) +#11 0x00007f5b6d37f417 g_main_context_dispatch (libglib-2.0.so.0) +#12 0x00005599030c5e0a glib_pollfds_poll (qemu-system-x86_64) +#13 0x0000559902dd75df main_loop (qemu-system-x86_64) +#14 0x0000559902c59f49 main (qemu-system-x86_64) +#15 0x00007f5b6bfeab97 __libc_start_main (libc.so.6) +#16 0x0000559902c5d38a _start (qemu-system-x86_64) + +#0 0x0000559902fd2d30 in object_get_class (obj=obj@entry=0x0) at ./qom/object.c:909 +#1 0x0000559903071020 in qio_channel_create_watch (ioc=0x0, condition=(G_IO_OUT | G_IO_HUP)) at ./io/channel.c:281 + klass = <optimized out> + __func__ = "qio_channel_create_watch" + ret = <optimized out> +#2 0x000055990305f437 in qemu_chr_fe_add_watch (be=be@entry=0x559905a7f460, cond=cond@entry=(G_IO_OUT | G_IO_HUP), func=func@entry=0x559902f734b0 <monitor_unblocked>, user_data=user_data@entry=0x559905a7f460) at ./chardev/char-fe.c:367 + s = 0x5599055782c0 + src = <optimized out> + tag = <optimized out> + __func__ = "qemu_chr_fe_add_watch" +#3 0x0000559902f7340d in monitor_flush_locked (mon=mon@entry=0x559905a7f460) at ./monitor/monitor.c:140 + rc = 219264 + len = 3865832 + buf = 0x7f5afc00e480 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"... +#4 0x0000559902f7360e in monitor_flush_locked (mon=0x559905a7f460) at ./monitor/monitor.c:160 + i = 3865830 + c = <optimized out> +#5 0x0000559902f7360e in monitor_puts (mon=mon@entry=0x559905a7f460, str=0x7f5aa1eda010 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"...) at ./monitor/monitor.c:167 + i = 3865830 + c = <optimized out> +#6 0x0000559902f74342 in qmp_send_response (mon=0x559905a7f460, rsp=<optimized out>) at ./monitor/qmp.c:119 + data = <optimized out> + json = 0x559906c88380 +#7 0x0000559902f74409 in monitor_qmp_respond (rsp=0x559905bbf740, mon=0x559905a7f460) at ./monitor/qmp.c:132 + old_mon = <optimized out> + rsp = 0x559905bbf740 + error = <optimized out> +#8 0x0000559902f74409 in monitor_qmp_dispatch (mon=0x559905a7f460, req=<optimized out>) at ./monitor/qmp.c:161 + old_mon = <optimized out> + rsp = 0x559905bbf740 + error = <optimized out> +#9 0x0000559902f74bc0 in monitor_qmp_bh_dispatcher (data=<optimized out>) at ./monitor/qmp.c:234 + id = <optimized out> + rsp = <optimized out> + need_resume = true + mon = 0x559905a7f460 + __PRETTY_FUNCTION__ = "monitor_qmp_bh_dispatcher" +#10 0x00005599030c37be in aio_bh_call (bh=0x559905571b40) at ./util/async.c:89 + bh = 0x559905571b40 + bhp = <optimized out> + next = 0x5599055718f0 + ret = 1 + deleted = false +#11 0x00005599030c37be in aio_bh_poll (ctx=ctx@entry=0x5599055706f0) at ./util/async.c:117 + bh = 0x559905571b40 + bhp = <optimized out> + next = 0x5599055718f0 + ret = 1 + deleted = false +#12 0x00005599030c6dd0 in aio_dispatch (ctx=0x5599055706f0) at ./util/aio-posix.c:459 +#13 0x00005599030c369e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./util/async.c:260 + ctx = <optimized out> +#14 0x00007f5b6d37f417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#15 0x00005599030c5e0a in glib_pollfds_poll () at ./util/main-loop.c:219 + context = 0x559905652420 + pfds = <optimized out> + context = 0x559905652420 + ret = 1 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#16 0x00005599030c5e0a in os_host_main_loop_wait (timeout=14451267) at ./util/main-loop.c:242 + context = 0x559905652420 + ret = 1 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#17 0x00005599030c5e0a in main_loop_wait (nonblocking=<optimized out>) at ./util/main-loop.c:518 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#18 0x0000559902dd75df in main_loop () at ./vl.c:1810 +#19 0x0000559902c59f49 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ./vl.c:4466 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x55990318bc94 "cad" + boot_once = <optimized out> + ds = <optimized out> + opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 100 + optarg = 0x7ffe0ca05e74 "timestamp=on" + loadvm = 0x0 + cpu_option = 0x7ffe0ca05d42 "SandyBridge-IBRS,-kvm_steal_time,+pcid,+ssbd,+spec-ctrl,+md-clear" + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + incoming = 0x0 + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = 0x0 + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe0ca03540} + plugin_list = {tqh_first = 0x0, tqh_circ = {tql_next = 0x0, tql_prev = 0x7ffe0ca03550}} + __func__ = "main" \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1891 b/results/classifier/accel-gemma3:12b/vmm/1891 new file mode 100644 index 000000000..267f09eac --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1891 @@ -0,0 +1,49 @@ + +qemu 8.1.0 breaks gvt-g + qemu-ui-gtk w gl=on (black screen, qemu: eglCreateImageKHR failed) +Description of problem: +As of 8.1.0, qemu-ui-gtk renders a black window with the error `qemu: eglCreateImageKHR failed` repeatedly appearing in the command line. + + +# +Steps to reproduce: +1. enable kernel modules, set parameters etc. +2. create vgpu + `echo "$GVT_GUID" > "/sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/i915-GVTg_V4_2/create"` +3. launch VM +4. wait + +Instructions (a small part of which I wrote by trial and error) for the setup are on the [Arch Wiki](https://wiki.archlinux.org/title/Intel_GVT-g). + +# +Additional information: +Windows is installed directly to a second SSD, I dual-boot it. +I've been using this exact VM, from libvirt, for almost two years. +relevant sections: +``` + <hostdev mode="subsystem" type="mdev" managed="no" model="vfio-pci" display="off"> + <source> + <address uuid="$GVT_GUID"/> + </source> + </hostdev> + </devices> + <qemu:commandline> + <qemu:arg value="-display"/> + <qemu:arg value="gtk,gl=on,zoom-to-fit=off"/> + <qemu:env name="DISPLAY" value=":0.0"/> + </qemu:commandline> + <qemu:override> + <qemu:device alias="hostdev0"> + <qemu:frontend> + <qemu:property name="x-igd-opregion" type="bool" value="true"/> + <qemu:property name="driver" type="string" value="vfio-pci-nohotplug"/> + <qemu:property name="ramfb" type="bool" value="true"/> + <qemu:property name="display" type="string" value="on"/> + <qemu:property name="romfile" type="string" value="/home/user/VM/vbios_gvt_uefi.rom"/> + </qemu:frontend> + </qemu:device> + </qemu:override> +``` + +The patched vBIOS necessary to use DMA-BUF with OVMF is linked there too, but its [successors](https://github.com/patmagauran/i915ovmfPkg) doesn't work either. + +# diff --git a/results/classifier/accel-gemma3:12b/vmm/1891830 b/results/classifier/accel-gemma3:12b/vmm/1891830 new file mode 100644 index 000000000..0c8f6e68a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1891830 @@ -0,0 +1,35 @@ + +msmouse serial mouse emulation broken? No id byte sent on reset + +I took a shot at getting Windows 1.01 working. It doesn't support a PS/2 mouse out-of-the-box but does support MS serial mice. It doesn't seem to detect qemu's emulated msmouse. + +When I run this command: + +> qemu-system-i386 -nodefaults -hda my_windows1_hd.qcow2 -vga std -serial msmouse -trace enable='serial*' -icount shift=10,align=on + +I get this output (edited): + +251908@1597626456.800452:serial_ioport_write write addr 0x04 val 0x01 +251908@1597626456.800460:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.800462:serial_ioport_read read addr 0x00 val 0x00 + +[snip] + +251908@1597626456.961641:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961642:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961644:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961647:serial_ioport_write write addr 0x04 val 0x0b +251908@1597626456.961648:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961684:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961685:serial_ioport_read read addr 0x05 val 0x60 + +[snip] + +251908@1597626457.045894:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045895:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045897:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045932:serial_ioport_read read addr 0x00 val 0x00 + +The write of 0x01 and then 0x0b to reg 0x04 is the guest turning the RTS line off then on. A real mouse will respond to this by sending 0x4d, which is how the guest detects the mouse. + +Reproducible in current stable-4.2 and 5.0 (debian's build). I am able to get the guest to use a real passed-through serial mouse (with a minor hack, separate bug filed for this) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1892541 b/results/classifier/accel-gemma3:12b/vmm/1892541 new file mode 100644 index 000000000..f04a588e5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1892541 @@ -0,0 +1,16 @@ + +qemu 5.1 on windows 10 with whpx can not install Windows 7 guest + +Command install and start win7 + +qemu-system-x86_64 -smbios type=1,uuid=e77aacd6-0acb-4a5c-9a83-a80d029b36f1 -smp 2,sockets=1,cores=2,maxcpus=2 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -m 8192 ^ +-readconfig pve-q35-4.0.cfg ^ +-device vmgenid,guid=6d4865f5-353e-4cf1-b8ca-f5abbd062736 -device usb-tablet,id=tablet,bus=ehci.0,port=1 -device VGA,id=vga,bus=pcie.0,addr=0x1 ^ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 ^ +-drive file=en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso,if=none,id=drive-ide2,media=cdrom,aio=threads ^ +-device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -device ahci,id=ahci0,multifunction=on,bus=pci.0,addr=0x7 ^ +-drive id=drive-sata0,if=none,file=win7.qcow2,format=qcow2,cache=none,aio=native,detect-zeroes=on ^ +-device ide-hd,bus=ahci0.0,drive=drive-sata0,id=sata0,bootindex=100 ^ +-netdev type=tap,id=mynet0,ifname=tap1,script=no,downscript=no ^ +-device e1000,netdev=mynet0,mac=52:55:00:d1:55:10,bus=pci.0,addr=0x12,id=net0,bootindex=300 ^ +-machine type=q35,accel=whpx \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1892544 b/results/classifier/accel-gemma3:12b/vmm/1892544 new file mode 100644 index 000000000..e4425b069 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1892544 @@ -0,0 +1,44 @@ + +meson qemu 5.2 can not built with msys2 + +pacman -S base-devel mingw-w64-x86_64-toolchain git +pacman -S mingw-w64-x86_64-python mingw-w64-x86_64-python-setuptools +pacman -S mingw-w64-x86_64-spice-protocol + +cd /mingw64/bin +cp x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-ar.exe +cp x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-ranlib.exe +cp windres.exe x86_64-w64-mingw32-windres.exe +cp nm.exe x86_64-w64-mingw32-nm.exe +cp objcopy.exe x86_64-w64-mingw32-objcopy.exe +cd ~ +cd qemu.org-x64 + + +../qemu.org/configure \ + --python=python3 \ + --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl \ + --enable-capstone=git \ + --enable-stack-protector \ + --enable-gnutls \ + --enable-nettle \ + --enable-vnc \ + --enable-vnc-sasl \ + --enable-vnc-jpeg \ + --enable-vnc-png \ + --enable-membarrier \ + --enable-slirp=git \ + --disable-kvm \ + --enable-hax \ + --enable-whpx \ + --disable-spice \ + --enable-lzo \ + --enable-snappy \ + --enable-bzip2 \ + --enable-vdi \ + --enable-qcow1 \ + --enable-tools \ + --enable-libusb \ + --enable-usb-redir \ + --disable-libnfs \ + --enable-libssh \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1892684 b/results/classifier/accel-gemma3:12b/vmm/1892684 new file mode 100644 index 000000000..3fa725289 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1892684 @@ -0,0 +1,25 @@ + +curl and wget segfaults when link has redirects + +Hello, + +I've been using qemu-user-static with aarch64 docker images and faced the problem +using binares from the following release: https://github.com/multiarch/qemu-user-static/releases/tag/v5.0.0-2. + +curl and wget fails with segmentation fault when trying to fetch something from the link +that has some redirects. + +In order to reproduce you can run the following: + +1) Register qemu on x86_64 machine + docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +2) Run arm64v8 docker image and try to run wget or curl + docker run --rm -it arm64v8/ubuntu bash + $ apt update + $ apt install curl wget + $ curl -L http://erratique.ch/software/astring/releases/astring-0.8.3.tbz + $ wget http://erratique.ch/software/astring/releases/astring-0.8.3.tbz + +This error cannot be reproduced with binaries from eariler release https://github.com/multiarch/qemu-user-static/releases/tag/v4.2.0-7. +curl and wget work fine with the given link and don't fail with segfault when using +older qemu-user-static binaries \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1894 b/results/classifier/accel-gemma3:12b/vmm/1894 new file mode 100644 index 000000000..7e3313dff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1894 @@ -0,0 +1,12 @@ + +Can't emulate audio with OpenCore Mac OS X 10.7 +Description of problem: +OpenCore wants me to use `AppleALC`, but to use _that_, I need the layout ID of the motherboard or something and I'm not sure how I'd do that since it's a QEMU VM. All I want to do is have some audio :( + +So, how can I emulate audio with AppleALC + OpenCore/how can I get a layout ID that'll give me audio on a QEMU VM? Do note that I am using UTM (https://getutm.app/) (UTM uses QEMU and is basically a QEMU frontend). +Steps to reproduce: +1. Set up OpenCore and install Mac OS X 10.7 +2. Copy across a .mp3 file +3. iTunes fails to play it due to no audio drivers/audio outputs +Additional information: +N/A diff --git a/results/classifier/accel-gemma3:12b/vmm/1894781 b/results/classifier/accel-gemma3:12b/vmm/1894781 new file mode 100644 index 000000000..c90bd666b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1894781 @@ -0,0 +1,20 @@ + +[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation) + +(following from https://gitlab.com/libvirt/libvirt/-/issues/68#note_400960567) + +As is very well explained in https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/, and easily confirmed with captures, NBD stream starts in cleartext and upgrades to TLS inline (similar to STARTTLS mechanism). As a rationale, it is stated that this provides better error messages for the user of NBD. + +However, this approach has downsides: + +1) Clear indication to a network observer that NBD (and therefore likely qemu/libvirt) is used. In contrast, TLS1.3 hides even the SNI of the servers (ESNI, https://blog.cloudflare.com/encrypted-sni/). +2) Potential for bugs in NBD protocol negotiation code. That code just statistically, likely less looked at code than gnutls. This is not a reflection on NBD code quality, just the fact that TLS code does receive a bit more scrutiny. +3) Inability to inspect TLS listener interface for compliance, e.g. with a security scanner. Making sure TLS listeners only select certain ciphersuits is a requirement of some compliance regimes. + +I think it's fully possible to satisfy the original requirement of good error messages as well, detecting that the other end is initiating TLS connection. + +It's very unlikely that it's currently sae to recommend to run QEMU migration stream over a hostile network, but it should be possible to do with TLS only option. + +Solution to this, just like in the case of SMTP, is to provide TLS only option (no initial cleartext at all) for QEMU migration, which hopefully it not a large addition. + +Thank you for your consideration! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1894818 b/results/classifier/accel-gemma3:12b/vmm/1894818 new file mode 100644 index 000000000..7f4c2d7f4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1894818 @@ -0,0 +1,20 @@ + +COLO's guest VNC client hang after failover + +Hello, + +After setting up COLO's primary and secondary VMs, +I installed the vncserver and xrdp (apt install tightvncserver xrdp) inside the VM. + +I access the VM from another PC via VNC/RDP client, and everything is OK. +Then, kill the primary VM and issue the failover commands. + +The expected result is that the VNC/RDP client can resume after failover. +But in my test, the VNC client's screen hangs and cannot be recovered no longer. + +BTW, it works well after killing SVM. + +Thanks. + +Regards, +Derek \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1894836 b/results/classifier/accel-gemma3:12b/vmm/1894836 new file mode 100644 index 000000000..c253ae401 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1894836 @@ -0,0 +1,47 @@ + +kernel panic using hvf with CPU passthrough + +Host Details +QEMU 5.1 (Homebrew) +macOS 10.15.6 Catalina +Late 2014 model +i5-4690 @ 3.5 GHz +8 GB RAM + +Guest Details +Ubuntu Desktop 20.04.1 Installer ISO + +Problem +Whenever I boot with "-accel hvf -cpu host", the Ubuntu desktop installer will immediately crash with a kernel panic after the initial splash screen. +See the attached picture of the kernel panic for more details. + +Steps to recreate +From https://www.jwillikers.com/posts/virtualize_ubuntu_desktop_on_macos_with_qemu/ + +1. Install QEMU with Homebrew. +$ brew install qemu + +2. Create a qcow2 disk image to which to install. +$ qemu-img create -f qcow2 ubuntu2004.qcow2 60G + +3. Download the ISO. +$ curl -L -o ubuntu-20.04.1-desktop-amd64.iso https://releases.ubuntu.com/20.04/ubuntu-20.04.1-desktop-amd64.iso + +4. Run the installer in QEMU. +$ qemu-system-x86_64 \ + -accel hvf \ + -cpu host \ + -smp 2 \ + -m 4G \ + -usb \ + -device usb-tablet \ + -vga virtio \ + -display default,show-cursor=on \ + -device virtio-net,netdev=vmnic -netdev user,id=vmnic \ + -audiodev coreaudio,id=snd0 \ + -device ich9-intel-hda -device hda-output,audiodev=snd0 \ + -cdrom ubuntu-20.04.1-desktop-amd64.iso \ + -drive file=ubuntu2004.qcow2,if=virtio + +Workaround +Emulating the CPU with "-cpu qemu64" does not result in a kernel panic. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1895053 b/results/classifier/accel-gemma3:12b/vmm/1895053 new file mode 100644 index 000000000..0243f9170 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1895053 @@ -0,0 +1,35 @@ + +Cannot nspawn raspbian 10 [FAILED] Failed to start Journal Service. + +Hi, I'm using nspawn and asked the question @systemd-devel. They redirected me to you, guessing that nspawn calls a syscall or ioctl qemu isnt aware of and can't implement properly? +They were like: "Sorry, that's not my department." ^^ + +Maybe you can reproduce the issue or help me investigating whats wrong or put the ball right back into their court? :D + +From: "chiasa.men" <email address hidden> +To: <email address hidden> +Date: 09.09.20 14:20 +(cf. https://github.com/systemd/systemd/issues/16975) + +Testscript: +wget https://downloads.raspberrypi.org/raspios_lite_armhf_latest -o r.zip +unzip r.zip +LOOP=$(losetup --show -Pf *raspios-buster-armhf-lite.img) +mount ${LOOP}p2 /mnt +mount ${LOOP}p1 /mnt/boot +systemd-nspawn --bind /usr/bin/qemu-arm-static --boot --directory=/mnt -- systemd.log_level=debug + + +Output: +see attachment + +System: +uname -a +Linux MArch 5.8.7-arch1-1 #1 SMP PREEMPT Sat, 05 Sep 2020 12:31:32 +0000 +x86_64 GNU/Linux + +systemd-nspawn --version +systemd 246 (246.4-1-arch) ++PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP ++GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN ++PCRE2 default-hierarchy=hybrid \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1895399 b/results/classifier/accel-gemma3:12b/vmm/1895399 new file mode 100644 index 000000000..5887ef9bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1895399 @@ -0,0 +1,26 @@ + +Docfix: add missing virtiofsd cache default 'auto' + +The usage command line for virtiofsd has: + +void fuse_cmdline_help(void) +{ + printf(" -h --help print help\n" +... + " -o cache=<mode> cache mode. could be one of \"auto, " + "always, none\"\n" + " default: auto\n" + + +But the default: auto info is missing from the man page. I suggest this patch: + +--- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 ++++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +@@ -106,6 +106,7 @@ + forbids the FUSE client from caching to achieve best coherency at the cost of + performance. ``auto`` acts similar to NFS with a 1 second metadata cache + timeout. ``always`` sets a long cache lifetime at the expense of coherency. ++ The default is ``auto``. + + Examples + -------- \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1896754 b/results/classifier/accel-gemma3:12b/vmm/1896754 new file mode 100644 index 000000000..5be9f3567 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1897568 b/results/classifier/accel-gemma3:12b/vmm/1897568 new file mode 100644 index 000000000..1e3385333 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1897568 @@ -0,0 +1,11 @@ + +Strange keyboard behaviour in Vim editor + + +I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a problem with the keyboard in the Vim editor. The arrow keys jump over a line, as if you had typed the key twice. PgUp and PgDn are likewise affected. Other applications are not affected, unless you shell out from Vim. + +The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've tried without it and it doesn't make a difference. + +I don't get this keyboard behaviour in the exact same VM under VMware Player or Bochs. + +-Albert. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1899 b/results/classifier/accel-gemma3:12b/vmm/1899 new file mode 100644 index 000000000..fe620c968 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1899 @@ -0,0 +1,42 @@ + +AArch64: Wrong SCR_EL3 after turning on secondary cores via PSCI +Description of problem: +The system fails to boot when using "direct kernel boot" with EL3 enabled. After the guest OS enables secondary cores via PSCI, those have an incorrectly set up `SCR_EL3`. When the OS then executes an intruction which traps into (QEMU provided fake) EL3, the core ends up in an endless loop of "Undefined Instruction" exceptions. + +This is nicely visible with `-serial stdio -append "earlycon=pl011,0x9000000 console=/dev/ttyAMA0" -d int`: + +```plaintext +[ 0.173173][ T1] smp: Bringing up secondary CPUs ... +(...) +Taking exception 11 [Hypervisor Call] on CPU 0 +...from EL1 to EL2 +...with ESR 0x16/0x5a000000 +...handled as PSCI call +Taking exception 5 [IRQ] on CPU 0 +...from EL1 to EL1 +...with ESR 0x16/0x5a000000 +...with ELR 0xffffa9ff8b593438 +...to EL1 PC 0xffffa9ff8aa11280 PSTATE 0x3c5 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffa9ff8b593438 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0x41f7832c +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL1 to EL3 +...with ESR 0x18/0x62300882 +...with ELR 0xffffa9ff8aa3d0d8 +...to EL3 PC 0x400 PSTATE 0x3cd +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL3 to EL3 +...with ESR 0x0/0x2000000 +...with ELR 0x400 +...to EL3 PC 0x200 PSTATE 0x3cd +(repeats forever, CPU 1 is stuck) +``` +Steps to reproduce: +1. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 1 -kernel linux` works +2. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 2 -kernel linux` does not +Additional information: +The setup for `SCR_EL3` is done by `do_cpu_reset` in hw/arm/boot.c, but this is only called on full system reset. The PSCI call ends up in `arm_set_cpu_on_async_work` (target/arm/arm-powerctl.c) which calls `cpu_reset`. This clears `SCR_EL3` to the architectural reset value, not the one needed for direct kernel boot. + +`arm_set_cpu_on_async_work` has code for `SCR_HCE`, but none of the other flags handled by `do_cpu_reset`. It would probably work after copying all of `do_cpu_reset` into `arm_set_cpu_on_async_work`, but that seems wrong. I prepared a patch which makes `do_cpu_reset` public such that `arm_set_cpu_on_async_work` can call it (works here), but I'm not sure whether that's the right way. + +CC @pm215 diff --git a/results/classifier/accel-gemma3:12b/vmm/1899539 b/results/classifier/accel-gemma3:12b/vmm/1899539 new file mode 100644 index 000000000..0f4d91d2f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1899539 @@ -0,0 +1,10 @@ + +keyboard errors in DOS, found links to similar errors for reference + +OS: slackware 14.2, updated. qemu version: 4.1.0 (from slackbuild script) + +command line: qemu-system-i386 -hda msdos.vhd + +Description of problem: MSDOS 6.22 disk image running gwbasic 3.23. Cursor keys and sometimes letter keys are repeated. Cursor keys seemingly always, letter keys seem to happen when typing too fast. Numpad arrows are not affected. Also insert key doesnt seem to work at all. + +Have found one similar current bug, Bug #1574246 Drunken keyboard in go32v2 programs https://bugs.launchpad.net/qemu/+bug/1574246?comments=all and a much older vbox bug report that seems very similar, https://www.virtualbox.org/ticket/58 , and for some reason mentions a qemu patch. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1900352 b/results/classifier/accel-gemma3:12b/vmm/1900352 new file mode 100644 index 000000000..b9033fe02 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1900352 @@ -0,0 +1,6 @@ + +no sound in spice when VNC enabled + +Running Fedora32 with virt-manager → libvirt → qemu I noticed that I got no sound in my spice client. The VM is configured with a SPICE-server and a QXL display, and in addition a VNC display. + +Apparently when I remove the VNC display, then the sound is routed just fine to the spice client: I can hear it, and `G_MESSAGES_DEBUG=all remote-viewer --spice-debug spice://localhost:5900` mentions SpicePlaybackChannel and SpiceRecordChannel. With the VNC server configured, such messages are missing, and I cannot hear the sound (which is sent by the guest OS to the virtual hardware). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1901068 b/results/classifier/accel-gemma3:12b/vmm/1901068 new file mode 100644 index 000000000..c9ff69365 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1901068 @@ -0,0 +1,13 @@ + +Deleted tests are still run if they exist in the build tree + +Steps to reproduce: +1. Add a new device along with a qtest to exercise it. +2. Run make check-qtest. It passes. +3. Revert the commit that added the device and qtest. +4. Run make check-qtest again. It now fails because the device no longer exists, but the test is somehow still there even though the source files are gone and it's not mentioned in tests/qtest/meson.build. + +After running make clean, make check-qtest passes again. + +$ git describe +v5.1.0-2465-g4c5b97bfd0 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1901892 b/results/classifier/accel-gemma3:12b/vmm/1901892 new file mode 100644 index 000000000..23802fe88 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1901892 @@ -0,0 +1,39 @@ + +qemu-img create corrupts the qcow2 if the file already exists + +When creating a disk using qemu-img create command, if the destination path of the qcow2 file already exists, it will show the error saying that it cannot get a lock so it exits with exit status 1 but it will corrupt the qcow2 file anyway. + +Steps to reproduce: +1. Have a guest running with a root (vda) and a second device (vdc). +In my case is a clean Ubuntu 16.04 image with kernel 4.4.0-190-generic x86_64 +vdc disk is called testadddisk-3.qcow2 +2. vdc is an xfs over lvm. +pvcreacte /dev/vdc +vgcreate myVg /dev/vdc +lvcreate -l+100%FREE -n myLv myVg +mkfs.xfs /dev/mapper/myVg-myLv +mount /dev/mapper/myVg-myLv /mnt +3. Create disk IO on that device in the guest. +while true ; do dd if=/dev/zero of=/mnt/testfile bs=1024 count=1000 ; sleep 1; done +4. Execute the command to create a new device but use the same name of the device attached: +sudo qemu-img create -f qcow2 testadddisk-3.qcow2 20G +The output of the command is this: +Formatting 'testadddisk-3.qcow2', fmt=qcow2 size=21474836480 cluster_size=65536 lazy_refcounts=off refcount_bits=16 +qemu-img: testadddisk-3.qcow2: Failed to get "write" lock +Is another process using the image? + +The write continues in the guest but when it is shutdown, when it is powered on again you get this: +error: Failed to start domain testadddisk +error: internal error: process exited while connecting to monitor: 2020-10-27T22:00:51.628374Z qemu-system-x86_64: -drive file=/var/lib/vmImages/testadddisk-3.qcow2,format=qcow2,if=none,id=drive-virtio-disk2: Image is not in qcow2 format + +I run the qemu-img create command with an strace and I believe that first it tries to open the file in write mode, then does a truncate on it and after that says it cannot get a lock. The output is in the file attached. As well as the guest xml just in case. + +The host: +Ubuntu 18.04.5 LTS +4.15.0-112-generic x86_64 +qemu packages installed: +ii qemu-block-extra:amd64 1:2.11+dfsg-1ubuntu7.32 amd64 extra block backend modules for qemu-system and qemu-utils +ii qemu-kvm 1:2.11+dfsg-1ubuntu7.31 amd64 QEMU Full virtualization on x86 hardware +ii qemu-system-common 1:2.11+dfsg-1ubuntu7.32 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 1:2.11+dfsg-1ubuntu7.31 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:2.11+dfsg-1ubuntu7.32 amd64 QEMU utilities \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1902 b/results/classifier/accel-gemma3:12b/vmm/1902 new file mode 100644 index 000000000..5aa3272b2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1902 @@ -0,0 +1,66 @@ + +Crash on macOS when screen resolution changes when using SDL UI frontend +Description of problem: +In the above configuration, booting NetBSD works fine up to the point where the kernel sets the framebuffer resolution for the console, which results in a window size change. At this point, the OS terminates the qemu process with this error message: + +``` +*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow geometry should only be modified on the main thread!' +*** First throw call stack: +( + 0 CoreFoundation 0x00000001849208c0 __exceptionPreprocess + 176 + 1 libobjc.A.dylib 0x0000000184419eb4 objc_exception_throw + 60 + 2 CoreFoundation 0x0000000184945bac _CFBundleGetValueForInfoKey + 0 + 3 AppKit 0x00000001880a6ab8 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 240 + 4 AppKit 0x00000001880b2a38 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 88 + 5 AppKit 0x00000001880c18a0 -[NSTitledFrame _titleDidChange] + 116 + 6 AppKit 0x0000000188a92f04 -[NSTitledFrame setTitle:subtitle:] + 420 + 7 AppKit 0x00000001880c1570 -[NSThemeFrame setTitle:] + 52 + 8 AppKit 0x000000018866e0fc -[NSFrameView _updateTitleProperties:animated:] + 44 + 9 AppKit 0x0000000188a85e98 -[NSThemeFrame _updateTitleProperties:animated:] + 156 + 10 CoreFoundation 0x00000001848a0780 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 + 11 CoreFoundation 0x00000001849349a8 ___CFXRegistrationPost_block_invoke + 88 + 12 CoreFoundation 0x00000001849348f0 _CFXRegistrationPost + 440 + 13 CoreFoundation 0x000000018486f434 _CFXNotificationPost + 764 + 14 Foundation 0x0000000185960c74 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 + 15 AppKit 0x000000018881da88 -[NSWindowTitleController _propertiesChanged:] + 128 + 16 AppKit 0x00000001880c1388 -[NSWindow _dosetTitle:andDefeatWrap:] + 156 + 17 libSDL2-2.0.0.dylib 0x0000000106aa9abc Cocoa_SetWindowTitle + 104 + 18 qemu-system-aarch64 0x0000000105006628 sdl_update_caption + 256 + 19 qemu-system-aarch64 0x0000000105007838 sdl_mouse_mode_change + 168 + 20 qemu-system-aarch64 0x00000001054ab100 notifier_list_notify + 36 + 21 qemu-system-aarch64 0x0000000104d28124 qemu_input_check_mode_change + 96 + 22 qemu-system-aarch64 0x0000000104e13a74 hid_pointer_activate + 32 + 23 qemu-system-aarch64 0x0000000104f44c2c usb_process_one + 464 + 24 qemu-system-aarch64 0x0000000104f4491c usb_handle_packet + 120 + 25 qemu-system-aarch64 0x0000000104f58a94 xhci_kick_epctx + 1888 + 26 qemu-system-aarch64 0x00000001052d8f78 memory_region_write_accessor + 264 + 27 qemu-system-aarch64 0x00000001052d8db8 access_with_adjusted_size + 348 + 28 qemu-system-aarch64 0x00000001052d8c04 memory_region_dispatch_write + 428 + 29 qemu-system-aarch64 0x00000001052e6cfc flatview_write_continue + 344 + 30 qemu-system-aarch64 0x00000001052e4068 flatview_write + 156 + 31 qemu-system-aarch64 0x00000001052e9424 subpage_write + 124 + 32 qemu-system-aarch64 0x00000001052d8db8 access_with_adjusted_size + 348 + 33 qemu-system-aarch64 0x00000001052d8c04 memory_region_dispatch_write + 428 + 34 qemu-system-aarch64 0x000000010532ebf4 io_writex + 184 + 35 qemu-system-aarch64 0x000000010532ed44 do_st_mmio_leN + 104 + 36 qemu-system-aarch64 0x0000000105323e78 do_st4_mmu + 536 + 37 ??? 0x0000000108a91750 0x0 + 4440266576 + 38 qemu-system-aarch64 0x00000001053108f0 cpu_tb_exec + 164 + 39 qemu-system-aarch64 0x0000000105311754 cpu_exec_loop + 1084 + 40 qemu-system-aarch64 0x0000000105310edc cpu_exec_setjmp + 48 + 41 qemu-system-aarch64 0x0000000105310dcc cpu_exec + 560 + 42 qemu-system-aarch64 0x0000000105332650 tcg_cpus_exec + 44 + 43 qemu-system-aarch64 0x0000000105332c1c mttcg_cpu_thread_fn + 240 + 44 qemu-system-aarch64 0x00000001054a7494 qemu_thread_start + 128 + 45 libsystem_pthread.dylib 0x00000001847cf034 _pthread_start + 136 + 46 libsystem_pthread.dylib 0x00000001847c9e3c thread_start + 8 +) +libc++abi: terminating due to uncaught exception of type NSException +``` + +I think there have been other bugs of a similar nature in the past with the Cocoa UI. The regression may be because of stricter checks in the new macOS version. +Steps to reproduce: +1. Start qemu (the QEMU_EFI.fd is from Tianocore EDK2). +2. Wait for the NetBSD kernel to set framebuffer resolution and observe the crash. + +With `-nographic`, the problem does not occur. diff --git a/results/classifier/accel-gemma3:12b/vmm/1902365 b/results/classifier/accel-gemma3:12b/vmm/1902365 new file mode 100644 index 000000000..3a663a303 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1902365 @@ -0,0 +1,391 @@ + +3x 100% host CPU core usage while virtual machine is in idle + +My Fedora 33 machine "top" command shows qemu-system-x86_64 process using ~300% CPU, that means 3x CPU cores at 100%. Since the virtual machine (named CentOS 8) is almost in idle (top command inside the VM shows ~0% CPU usage), there must be something wrong. I attach qemu process GDB backtrace, and virtual machine libvirt XML + +Host details: +libvirt-6.6.0-2.fc33.x86_64 +qemu-system-x86-5.1.0-5.fc33.x86_64 +virt-manager-3.1.0-1.fc33.noarch +kernel 5.8.16-300.fc33.x86_64 +CPU: AMD Ryzen 5 3600 + +# gdb qemu-system-x86_64 405756 +GNU gdb (GDB) Fedora 9.2-7.fc33 +Copyright (C) 2020 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-system-x86_64... +Reading symbols from .gnu_debugdata for /usr/bin/qemu-system-x86_64... +(No debugging symbols found in .gnu_debugdata for /usr/bin/qemu-system-x86_64) +Attaching to program: /usr/bin/qemu-system-x86_64, process 405756 +[New LWP 405788] +[New LWP 405798] +[New LWP 405799] +[New LWP 405800] +[New LWP 405801] +[New LWP 405802] +[New LWP 405804] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +0x00007f549d0bdb0e in ppoll () from target:/lib64/libc.so.6 +(gdb) set height 0 +(gdb) set print elements 0 +(gdb) set print frame-arguments all +(gdb) thread apply all backtrace + +Thread 8 (Thread 0x7f53837ff640 (LWP 405804)): +#0 0x00007f549d0bda0f in poll () from target:/lib64/libc.so.6 +#1 0x00007f549e4c2d1e in g_main_context_iterate.constprop () from target:/lib64/libglib-2.0.so.0 +#2 0x00007f549e4716ab in g_main_loop_run () from target:/lib64/libglib-2.0.so.0 +#3 0x00007f549dcfcc66 in red_worker_main.lto_priv () from target:/lib64/libspice-server.so.1 +#4 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#5 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 7 (Thread 0x7f5390dfd640 (LWP 405802)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 6 (Thread 0x7f53915fe640 (LWP 405801)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 5 (Thread 0x7f5391dff640 (LWP 405800)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 4 (Thread 0x7f54988b7640 (LWP 405799)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 3 (Thread 0x7f549917b640 (LWP 405798)): +#0 0x00007f549d0bda0f in poll () from target:/lib64/libc.so.6 +#1 0x00007f549e4c2d1e in g_main_context_iterate.constprop () from target:/lib64/libglib-2.0.so.0 +#2 0x00007f549e4716ab in g_main_loop_run () from target:/lib64/libglib-2.0.so.0 +#3 0x000055a6073c4c81 in iothread_run () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 2 (Thread 0x7f549b93a640 (LWP 405788)): +#0 0x00007f549d0c350d in syscall () from target:/lib64/libc.so.6 +#1 0x000055a6076dce9a in qemu_event_wait () +#2 0x000055a6076e56ca in call_rcu_thread () +#3 0x000055a6076dc0ff in qemu_thread_start () +#4 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#5 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 1 (Thread 0x7f549bb10f00 (LWP 405756)): +#0 0x00007f549d0bdb0e in ppoll () from target:/lib64/libc.so.6 +#1 0x000055a6076f4901 in qemu_poll_ns () +#2 0x000055a6076f0485 in main_loop_wait () +#3 0x000055a60735cdd7 in qemu_main_loop () +#4 0x000055a607234a1e in main () +(gdb) + + + + +# virsh dumpxml centos8 +<domain type='kvm' id='1'> + <name>centos8</name> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://centos.org/centos/8"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>4096000</memory> + <currentMemory unit='KiB'>4096000</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='clwb'/> + <feature policy='require' name='umip'/> + <feature policy='require' name='rdpid'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='perfctr_core'/> + <feature policy='require' name='clzero'/> + <feature policy='require' name='xsaveerptr'/> + <feature policy='require' name='wbnoinvd'/> + <feature policy='require' name='amd-stibp'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='disable' name='npt'/> + <feature policy='disable' name='nrip-save'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + <feature policy='disable' name='monitor'/> + <feature policy='disable' name='svm'/> + <feature policy='require' name='topoext'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8.qcow2' index='6'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-1.qcow2' index='5'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-2.qcow2' index='4'/> + <backingStore/> + <target dev='vdc' bus='virtio'/> + <alias name='virtio-disk2'/> + <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-3.qcow2' index='3'/> + <backingStore/> + <target dev='vdd' bus='virtio'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-4.qcow2' index='2'/> + <backingStore/> + <target dev='vde' bus='virtio'/> + <alias name='virtio-disk4'/> + <address type='pci' domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu'/> + <target dev='sda' bus='sata'/> + <readonly/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='sata' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'> + <alias name='pcie.0'/> + </controller> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <alias name='pci.1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <alias name='pci.2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <alias name='pci.3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <alias name='pci.4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <alias name='pci.5'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <alias name='pci.6'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='pci' index='7' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='7' port='0x16'/> + <alias name='pci.7'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> + </controller> + <controller type='pci' index='8' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='8' port='0x17'/> + <alias name='pci.8'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/> + </controller> + <controller type='pci' index='9' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='9' port='0x18'/> + <alias name='pci.9'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='10' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='10' port='0x19'/> + <alias name='pci.10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d4:02:c2'/> + <source network='default' portid='643b50a3-f347-4c2e-995e-7644a7ad0a96' bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/4'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/4'> + <source path='/dev/pts/4'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-centos8/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0' state='connected'/> + <alias name='channel1'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + <image compression='off'/> + </graphics> + <sound model='ich9'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir0'/> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir1'/> + <address type='usb' bus='0' port='3'/> + </redirdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </rng> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c571,c902</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c571,c902</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1902470 b/results/classifier/accel-gemma3:12b/vmm/1902470 new file mode 100644 index 000000000..b56eb02e1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1902470 @@ -0,0 +1,99 @@ + +migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts + +hi, + +I found that the multi-channel TLS-handshake will be stuck when the dst-libvirtd restarts, both the src and dst sockets are blocked in recvmsg. In the meantime, live_migration thread is blocked in multifd_send_sync_main, so +migration cannot be cancelled though src-libvirt has delivered the QMP command. + +Is there any way to exit migration when the multi-channel TLS-handshake is stuck? Does setting TLS handshake timeout function take effect? + +The stack trace are as follows: + +=====src qemu-system-aar stack=====: +#0 0x0000ffff87d6f28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae3817424 in qio_channel_socket_readv (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +#2 0x0000aaaae380f468 in qio_channel_readv_full (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +#3 0x0000aaaae380f9e8 in qio_channel_read (ioc=0xaaaae9e30a30, buf=0xaaaaea204e9b "\026\003\001\001L\001", buflen=5, errp=0x0) at ../io/channel.c:217 +#4 0x0000aaaae380e7d4 in qio_channel_tls_read_handler (buf=0xaaaaea204e9b "\026\003\001\001L\001", len=5, opaque=0xfffd38001190) at ../io/channel-tls.c:53 +#5 0x0000aaaae3801114 in qcrypto_tls_session_pull (opaque=0xaaaae99d5700, buf=0xaaaaea204e9b, len=5) at ../crypto/tlssession.c:89 +#6 0x0000ffff8822ed30 in _gnutls_stream_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:346 +#7 _gnutls_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:426 +#8 _gnutls_io_read_buffered (session=session@entry=0xaaaae983cd60, total=5, recv_type=recv_type@entry=4294967295, ms=0xffffdb58eaac) at buffers.c:581 +#9 0x0000ffff88224954 in recv_headers (ms=<optimized out>, record=0xffff883cd000 <email address hidden>, htype=65535, type=2284006288, + record_params=0xaaaae9e22a60, session=0xaaaae983cd60) at record.c:1163 +#10 _gnutls_recv_in_buffers (session=session@entry=0xaaaae983cd60, type=2284006288, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, + ms=<optimized out>, ms@entry=0) at record.c:1302 +#11 0x0000ffff88230568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaae983cd60, htype=htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, hsk=hsk@entry=0xffffdb58ec38, + optional=optional@entry=1) at buffers.c:1445 +#12 0x0000ffff88232b90 in _gnutls_recv_handshake (session=session@entry=0xaaaae983cd60, type=type@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, optional=optional@entry=1, + buf=buf@entry=0x0) at handshake.c:1534 +#13 0x0000ffff88235b40 in handshake_client (session=session@entry=0xaaaae983cd60) at handshake.c:2925 +#14 0x0000ffff88237824 in gnutls_handshake (session=0xaaaae983cd60) at handshake.c:2739 +#15 0x0000aaaae380213c in qcrypto_tls_session_handshake (session=0xaaaae99d5700, errp=0xffffdb58ee58) at ../crypto/tlssession.c:493 +#16 0x0000aaaae380ea40 in qio_channel_tls_handshake_task (ioc=0xfffd38001190, task=0xaaaaea61d4e0, context=0x0) at ../io/channel-tls.c:161 +#17 0x0000aaaae380ec60 in qio_channel_tls_handshake (ioc=0xfffd38001190, func=0xaaaae3394d20 <multifd_tls_outgoing_handshake>, opaque=0xaaaaea189c30, destroy=0x0, context=0x0) + at ../io/channel-tls.c:239 +#18 0x0000aaaae3394e78 in multifd_tls_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, errp=0xffffdb58ef28) at ../migration/multifd.c:782 +#19 0x0000aaaae3394f30 in multifd_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, error=0x0) at ../migration/multifd.c:804 +#20 0x0000aaaae33950b8 in multifd_new_send_channel_async (task=0xaaaaea6855a0, opaque=0xaaaaea189c30) at ../migration/multifd.c:858 +#21 0x0000aaaae3810cf8 in qio_task_complete (task=0xaaaaea6855a0) at ../io/task.c:197 +#22 0x0000aaaae381096c in qio_task_thread_result (opaque=0xaaaaea6855a0) at ../io/task.c:112 +#23 0x0000ffff88701df8 in ?? () from target:/usr/lib64/libglib-2.0.so.0 +#24 0x0000ffff88705a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +#25 0x0000aaaae3a5a29c in glib_pollfds_poll () at ../util/main-loop.c:221 +#26 0x0000aaaae3a5a324 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +#27 0x0000aaaae3a5a444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#28 0x0000aaaae3696b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +#29 0x0000aaaae30949e4 in main (argc=81, argv=0xffffdb58f2c8, envp=0xffffdb58f558) at ../softmmu/main.c:50 + +=====src live_migration stack=====: +#0 0x0000ffff87d6a5d8 in pthread_cond_wait () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae3a5f3ec in qemu_sem_wait (sem=0xaaaaea189d40) at ../util/qemu-thread-posix.c:328 +#2 0x0000aaaae3394838 in multifd_send_sync_main (f=0xaaaae983f0e0) at ../migration/multifd.c:638 +#3 0x0000aaaae37de310 in ram_save_setup (f=0xaaaae983f0e0, opaque=0xaaaae4198708 <ram_state>) at ../migration/ram.c:2588 +#4 0x0000aaaae31cf7ac in qemu_savevm_state_setup (f=0xaaaae983f0e0) at ../migration/savevm.c:1176 +#5 0x0000aaaae3248360 in migration_thread (opaque=0xaaaae9829f20) at ../migration/migration.c:3521 +#6 0x0000aaaae3a5f8fc in qemu_thread_start (args=0xaaaaea513ee0) at ../util/qemu-thread-posix.c:521 +#7 0x0000ffff87d647ac in ?? () from target:/usr/lib64/libpthread.so.0 +#8 0x0000ffff87cba6ec in ?? () from target:/usr/lib64/libc.so.6 + +=====dst qemu-system-aar stack=====: +#0 0x0000ffff7f17d28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae263a424 in qio_channel_socket_readv (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +#2 0x0000aaaae2632468 in qio_channel_readv_full (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +#3 0x0000aaaae26329e8 in qio_channel_read (ioc=0xaaaaf998a800, + buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., buflen=5, errp=0x0) + at ../io/channel.c:217 +#4 0x0000aaaae26317d4 in qio_channel_tls_read_handler ( + buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., len=5, + opaque=0xaaaaf9c4c400) at ../io/channel-tls.c:53 +#5 0x0000aaaae2624114 in qcrypto_tls_session_pull (opaque=0xaaaafa4a3d90, buf=0xaaaafa926dbb, len=5) at ../crypto/tlssession.c:89 +#6 0x0000ffff7f63cd30 in _gnutls_stream_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:346 +#7 _gnutls_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:426 +#8 _gnutls_io_read_buffered (session=session@entry=0xaaaafa58b9d0, total=5, recv_type=recv_type@entry=4294967295, ms=0xfffff5d2317c) at buffers.c:581 +#9 0x0000ffff7f632954 in recv_headers (ms=<optimized out>, record=0x1ee2a9fa78, htype=65535, type=2137262992, record_params=0xaaaafa4b71a0, session=0xaaaafa58b9d0) at record.c:1163 +#10 _gnutls_recv_in_buffers (session=session@entry=0xaaaafa58b9d0, type=2137262992, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, + ms=<optimized out>, ms@entry=0) at record.c:1302 +#11 0x0000ffff7f63e568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaafa58b9d0, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, hsk=hsk@entry=0xfffff5d23308, + optional=optional@entry=0) at buffers.c:1445 +#12 0x0000ffff7f640b90 in _gnutls_recv_handshake (session=session@entry=0xaaaafa58b9d0, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=optional@entry=0, buf=buf@entry=0x0) + at handshake.c:1534 +#13 0x0000ffff7f645f18 in handshake_server (session=<optimized out>) at handshake.c:3351 +#14 gnutls_handshake (session=0xaaaafa58b9d0) at handshake.c:2742 +#15 0x0000aaaae262513c in qcrypto_tls_session_handshake (session=0xaaaafa4a3d90, errp=0xfffff5d23478) at ../crypto/tlssession.c:493 +#16 0x0000aaaae2631a40 in qio_channel_tls_handshake_task (ioc=0xaaaaf9c4c400, task=0xaaaafa70e600, context=0x0) at ../io/channel-tls.c:161 +#17 0x0000aaaae2631c60 in qio_channel_tls_handshake (ioc=0xaaaaf9c4c400, func=0xaaaae20d4b58 <migration_tls_incoming_handshake>, opaque=0x0, destroy=0x0, context=0x0) + at ../io/channel-tls.c:239 +#18 0x0000aaaae20d4ca8 in migration_tls_channel_process_incoming (s=0xaaaaf9b2ef20, ioc=0xaaaaf998a800, errp=0xfffff5d23548) at ../migration/tls.c:103 +#19 0x0000aaaae20f9f7c in migration_channel_process_incoming (ioc=0xaaaaf998a800) at ../migration/channel.c:42 +#20 0x0000aaaae1f484a8 in socket_accept_incoming_migration (listener=0xffff64007a40, cioc=0xaaaaf998a800, opaque=0x0) at ../migration/socket.c:130 +#21 0x0000aaaae2638570 in qio_net_listener_channel_func (ioc=0xaaaafa410600, condition=G_IO_IN, opaque=0xffff64007a40) at ../io/net-listener.c:54 +#22 0x0000aaaae263ac4c in qio_channel_fd_source_dispatch (source=0xaaaafa81a380, callback=0xaaaae26384f8 <qio_net_listener_channel_func>, user_data=0xffff64007a40) + at ../io/channel-watch.c:84 +#23 0x0000ffff7fb13a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +#24 0x0000aaaae287d29c in glib_pollfds_poll () at ../util/main-loop.c:221 +#25 0x0000aaaae287d324 in os_host_main_loop_wait (timeout=571000000) at ../util/main-loop.c:244 +#26 0x0000aaaae287d444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#27 0x0000aaaae24b9b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +#28 0x0000aaaae1eb79e4 in main (argc=83, argv=0xfffff5d238c8, envp=0xfffff5d23b68) at ../softmmu/main.c:50 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1902777 b/results/classifier/accel-gemma3:12b/vmm/1902777 new file mode 100644 index 000000000..e23cb0435 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1902777 @@ -0,0 +1,13 @@ + +qemu with whpx acceleration crashes with vmx=on + +Under Windows 10, qemu crashes when using whpx acceleration and the vmx=on option. The reported error is + qemu-system-x86_64.exe: WHPX: Unexpected VP exit code 4 +Before the error, it reports + Windows Hypervisor Platform accelerator is operational + +The command line is the following: + "C:\Program Files\qemu\qemu-system-x86_64.exe" -accel whpx -cpu qemu64,vmx=on +It crashes with any model of CPU as long as the "vmx=on" option is added. Without this option it runs fine (but no nested virtualization). + +My processor is an Intel i7-10510U, and I am running Windows 10 2004 (build 19041.572). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1903470 b/results/classifier/accel-gemma3:12b/vmm/1903470 new file mode 100644 index 000000000..7462c8dbc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1903470 @@ -0,0 +1,10 @@ + +qemu 5.1.0: Add UNIX socket support for netdev socket + +qemu has a way to connect instances using a socket: + +-netdev socket,id=str[,fd=h][,listen=[host]:port][,connect=host:port] + +This can also be used to connect a qemu instance to something else using a socket connection, however there is no authentication or security to the connection, so rather than using a port which can be accessed by any user on the machine, having the ability to use or connect to UNIX sockets would be helpful, and adding this option should be fairly trivial. + +UNIX sockets can be found in various parts of qemu (monitor, etc) so I believe having this on network would make sense. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1903493 b/results/classifier/accel-gemma3:12b/vmm/1903493 new file mode 100644 index 000000000..43bb1216b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1903493 @@ -0,0 +1,4 @@ + +About wireless network card bridging + +As a rookie, I don’t know if I should ask this question here. If it’s not right, I hope people who see it can help submit it to the right place. Qemu-kvm can add wireless network card bridging, after all, now you see that vbox and vmware can directly choose wireless network card bridging, and even hyper-v can be easily set up, arp proxy is too difficult for us rookies . I hope that qemu or other links can add a function to bridge the wireless network card, which can be directly set in virt-manager (for so many years, it seems that I can only use bridge-utils to bridge the Ethernet) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1903833 b/results/classifier/accel-gemma3:12b/vmm/1903833 new file mode 100644 index 000000000..bc5f97ffc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1903833 @@ -0,0 +1,12 @@ + +User mode qemu-aarch: SIGGSEGV signal handler works wrong + +I have a user mode qemu-aarch issue. Program with SIGSEGV signal handler works wrong under qemu-aarch: +once the progam handles the SEGV signal, qemu marks the program's page protected, and signal handler gets SEGV on each subsequent memory access instruction within a program. + +The issue is reproduced on WSL Ubuntu 20.04 under Windows 10, qemu-aarch64 version 5.1.50 +The issue is also reproducible on the latest upstream qemu-aarch build. + +The following workaround disables mprotect call and fixes the issue: https://github.com/BorisUlasevich/qemu/commit/3063d9a64f8395185d65c6b6710d28ee92cd8be5 + +The issue can be reproduced on OpenJDK which reports SIGSEGV immediately after start. The small reproducer program is attached. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1904315 b/results/classifier/accel-gemma3:12b/vmm/1904315 new file mode 100644 index 000000000..1d90f556c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1904315 @@ -0,0 +1,24 @@ + +CTRL+ALT is ignored on gtk window (configured with gtk and sdl) + +I am building and using qemu on Windows 10 via git. +Building for targeting windows, on debian. + +Since meson is introduced, my executable, qemu-system-x86_64.exe, tends to ignore hotkeys +(like CTRL+ATL+G, CTRL+ALT+2) + +As far as I have been investigating the issue, I am suspicious that gtk and sdl might be incompatible. +With configure --disable-sdl, my executable works fine. +My application doesn't require sdl. + +Possibly due to link order, especially SDLmain, I guess. + +I suggest; +- Clarify that gtk and sdl are incompatible. +- Tweak built script or startup not to prevent gtk and sdl each other. + +Excuse me, the issue has not been reproduced at home yet. I met it at work. +(My manager said it's fine to report issues by me at home) +I will construct reproducible environment at home, if my further investigation would be required. + +Thanks. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1905 b/results/classifier/accel-gemma3:12b/vmm/1905 new file mode 100644 index 000000000..f08638f87 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1905 @@ -0,0 +1,4 @@ + +Allow for copying text from serial output +Additional information: +In addition to the serial output, it would be beneficial if this copy feature could also be extended to the QEMU monitor and parallel output. diff --git a/results/classifier/accel-gemma3:12b/vmm/1905037 b/results/classifier/accel-gemma3:12b/vmm/1905037 new file mode 100644 index 000000000..cb118c162 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1905037 @@ -0,0 +1,87 @@ + +Qemu SPARC64 Panics on Sun Solaris 5.8 - BOP_ALLOC failed + +Hi, + +Running Sun Solaris 5.8 by SPARC64, will panic by "BOP_ALLOC failed": + +$ qemu-system-sparc64 \ + -drive file=sparc.qcow2,if=ide,bus=0,unit=0 \ + -drive file=sun5.8.no1.iso,format=raw,if=ide,bus=1,unit=0,media=cdrom,readonly=on \ + -boot d +$ qemu-system-sparc64 -M sun4u -boot d -cdrom sun5.8.no1.iso -net nic -net user -m 2048 + +Both commands will raise this error: + +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 5936 bytes +entry point is 0x4000 +Evaluating FCode... +open isn't unique. +Alloc of 0x2000 bytes at 0x16000 refused. + +panic[cpu0]/thread=10408000: BOP_ALLOC failed + +0000000010406ea0 unix:boot_alloc+44 (2000, 2000, 1000, 30000016000, 31002afd100, 30000014000) + %l0-3: 000000001041b2d0 0000030ffffff138 0000000000000001 000000001044bdc0 + %l4-7: 000000001044af18 000000001044aef8 000000001044bd20 000000000000000b +0000000010406f50 unix:segkmem_alloc+30 (30000016000, 2000, 0, 0, 1044efe0, 1044b300) + %l0-3: 0000030ffffff5c0 ffffffffffffe000 0000000000000000 000000001044bdc0 + %l4-7: 000000001044af18 000000001044aef8 000000001044f840 000000001004a438 +0000000010407010 genunix:vmem_xalloc+3e4 (1044ea18, 1044ee20, ffffffffffffffff, ffffffffffffffff, 0, 0) + %l0-3: 000000001004a3b4 ffffffffffffe000 000000001044ea18 0000000000002000 + %l4-7: 0000000000000000 0000000000000000 0000000000002000 000000001044ea38 +0000000010407140 genunix:kmem_slab_create+8c (0, 0, 2000, 300000043c0, 0, 1044ea18) + %l0-3: 0000000000000000 0000030ffffff220 0000000000000000 000000001044bdc0 + %l4-7: 000000001044af18 00000300000043c0 000000001044f840 0000000000007fa3 +0000000010407230 genunix:kmem_cache_alloc+180 (0, 0, 0, 300000043c0, 0, 0) + %l0-3: 0000030000004740 ffffffffffffe000 000000001044ea18 0000000000002000 + %l4-7: 0000030ffffff220 0000000000000000 0000000000002000 000000001044ea38 +00000000104072e0 genunix:kmem_slab_create+130 (200, 30000014000, 2000, 3000000da40, 0, 200) + %l0-3: 0000000000000000 ffffffffffffe000 000000001044ea18 0000000000002000 + %l4-7: 0000030fffffef68 000003000000da40 0000000000002000 000000001044ea38 +00000000104073d0 genunix:kmem_cache_alloc+180 (0, 0, 0, 3000000da40, 0, 0) + %l0-3: 000003000000ddc0 0000000000000000 0000000000010000 ffffffffffffffff + %l4-7: 0000030000013fc8 00000300000052c0 0000030000013fc8 0000030000013fc0 +0000000010407480 genunix:kmem_alloc+2c (2000, 0, 2000, 3000000da40, 0, 30000013fb8) + %l0-3: 0000030000005640 0000000010147bfa 0000000000000000 0000000000000020 + %l4-7: 0000000010446678 0000000010452543 0000000000000000 0000000000000000 +0000000010407530 krtld:kobj_zalloc+c (2000, 1000, 2000, 300000052c0, f0, 0) + %l0-3: 000003000000e740 ffffffffffffffc0 000000001044f8e0 00000000000003c0 + %l4-7: 000000001044aa70 0000000000000000 0000000000000000 000000000000000b +00000000104075e0 krtld:kobj_open_file+38 (2000, 30000011f88, 104397f0, 0, 0, 1) + %l0-3: 0000000000000008 0000000000000000 0000000000000000 0000000000000000 + %l4-7: 0000000000000008 000000001004a3b4 0000000010452538 000000001004a438 +0000000010407690 genunix:mod_read_system_file+70 (10437c00, 2000, 1, 0, 26, 1043a0d8) + %l0-3: 0000000000004000 0000000000000008 0000000000004008 0000000000000000 + %l4-7: 0000000000002000 000000001004a3b4 0000000010451670 000000001004a438 +00000000104077b0 genunix:kmem_init+1b8 (10471b50, 0, 0, 91, 1, 291) + %l0-3: 000000001041dc00 0000000000002000 000000001004a3b4 000000001004a438 + %l4-7: 0000000010418590 0000000000001fff 000000001040d970 0000000000007fa3 +0000000010407880 unix:startup_memlist+b14 (10418400, 30000016080, 30000000000, 10418668, 2000, 30000016000) + %l0-3: 0000000000000103 0000000010423c00 0000000000000020 0000031002c00000 + %l4-7: 0000000010418400 000000001041d000 000000001041c000 000000001041b000 +0000000010407970 unix:startup+c (10428c00, 0, 0, 1, 0, ffffffffffffffff) + %l0-3: 0000000010026090 000000000000d925 0000000000000afd 0000000000000000 + %l4-7: 0000000010472880 00000000002e8c43 00000000000beafd 0000000000000afd +0000000010407a20 genunix:main+4 (1040d400, 2000, 10407ec0, 10408030, fff2, 10052a0c) + %l0-3: 0000000010408000 0000000000000001 0000000000000015 0000000000000f36 + %l4-7: 0000000010429618 0000000010472880 00000000000d7438 0000000000000540 + +skipping system dump - no dump device configured +rebooting... +BOOTpanic - kernel: prom_reboot: reboot call returned! +EXIT + +I'm not sure, but I think changes in this issue https://bugs.launchpad.net/qemu/+bug/1892540 might fix this one as well. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1905651 b/results/classifier/accel-gemma3:12b/vmm/1905651 new file mode 100644 index 000000000..c26ca828f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1905651 @@ -0,0 +1,53 @@ + +Tests cannot call g_error + +I stumbled on this writing a new test, using tests/qtest/e1000e-test.c as a template. + +g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get run. +This in turn means qemu is not killed, which hangs the test because the tap-driver.pl script hangs waiting for more input. +There are a few tests that call g_error(). + +The SIGABRT handler explicitly kills qemu, e.g.: + +qos-test.c: + qtest_add_abrt_handler(kill_qemu_hook_func, s); + +ref: +https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272 + +But not unexpectedly there's no such handler for SIGTRAP. + +Apply this patch to trigger a repro: + +diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c +index fc226fdfeb..e83ace1b5c 100644 +--- a/tests/qtest/e1000e-test.c ++++ b/tests/qtest/e1000e-test.c +@@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int *test_sockets, QGuestAllocator *a + /* Wait for TX WB interrupt */ + e1000e_wait_isr(d, E1000E_TX0_MSG_ID); + ++ g_message("Test g_error hang ..."); ++ g_error("Pretend something timed out"); ++ + /* Check DD bit */ + g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd); + +Then: + +configure +make +make check-qtest-i386 + +check-qtest-i386 will take awhile. To repro faster: + +$ grep qtest-i386/qos-test Makefile.mtest +.test.name.229 := qtest-i386/qos-test +$ make run-test-229 +Running test qtest-i386/qos-test +** Message: 18:40:49.821: Test g_error hang ... + +** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something timed out +ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out + +At this point things are hung because tap-driver.pl is still waiting for input because qemu is still running. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1905979 b/results/classifier/accel-gemma3:12b/vmm/1905979 new file mode 100644 index 000000000..58fe462ed --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1905979 @@ -0,0 +1,16 @@ + +Check if F_OFD_SETLK is supported may give wrong result + +In util/osdep.c there is a function qemu_probe_lock_ops() to check if file locks F_OFD_SETLK and F_OFD_GETLK (of the style "Open file description locks (non-POSIX)") are supported. + +This test is done by trying a lock operation on the file /dev/null. + +This test can get a wrong result. + +The result is (probably) if the operating system *in general* supports these locks. However, it does not guarantee that the file system where the lock is really wanted (for instance, in caller raw_check_lock_bytes() in block/file-posix.c) does support these locks. + +(In theory it could even be that /dev/null, being a device special file, does not support the lock type while a plain file would.) + +This is in particular relevant for disk images which are stored on a shared file system (my particular use case is the Quobyte file system, which appears not to support these locks). + +The code as mentioned above is present in the master branch (I checked commit ea8208249d1082eae0444934efb3b59cd3183f05) but also for example on stable-2.11 commit 0982a56a551556c704dc15752dabf57b4be1c640) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1906155 b/results/classifier/accel-gemma3:12b/vmm/1906155 new file mode 100644 index 000000000..25623b617 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1906155 @@ -0,0 +1,14 @@ + +USB Passthrough Fails on Start, Needs domain Reset + +Hi, + +I am seeing (consistently = always), USB Passthrough for my Logitech Keyboard and Mouse ... they don't work / no response on domain (VM) startup. After a reset of the VM they then work - but why are they "dead" on initial startup of the VM? Is this a known issue? + +Running, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +And if it makes a difference, this is a macOS guest (on a Linux host). + +Thanks! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1906156 b/results/classifier/accel-gemma3:12b/vmm/1906156 new file mode 100644 index 000000000..1c1fbef97 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1906156 @@ -0,0 +1,16 @@ + +Host OS Reboot Required, for Guest kext to Load (Fully) + +Hi, + +Finding this one a bit odd, but I am loading a driver (kext) in a macOS guest ... and it works, on the first VM (domain) startup after a full / clean host OS boot (or reboot). However, if I even reboot the guest OS, then the driver load fails => can be "corrected" by a full host OS reboot (which seems very extreme). + +Is this a known issue, and/or is there a workaround? + +FYI, running, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +This is for a macOS guest, on a Linux host. + +Thanks! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1907061 b/results/classifier/accel-gemma3:12b/vmm/1907061 new file mode 100644 index 000000000..75ea4dc5d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1907061 @@ -0,0 +1,16 @@ + +qemu-system-x86_64 minimizing window causes keyboard input lag globally + +After qemu window is minimized, it causes keyboard lag on the host for all applications, pressed keys will be delayed and very laggy, typing to notepad or any other text extremely slowly appear on the screen, queue is slowly processed. +If qemu window is open back to normal size, keyboard is back to normal, everything is back to normal and stable, this behavior i have been testing since several months of qemu releases, i am reporting a bit late here, not breaking but it seems important and everytime i accidently minimize qemu, i remember it later and take qemu window to normal size back always, i try never minimize it anymore. +This problem does not occur if using -display none +Guest OS doesn't matter for this behavior, result is always same +I am using: +qemu 5.1.0.0 +qemu-system-x86_64w.exe +Windows 10 build 2004 +4K screen dpi scaling set to 150% + +If requested, i can record a video to see the problem clearly, but i think all information i give already clear now. + +Thanks for making quality software, hope all bugs fixed \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1907952 b/results/classifier/accel-gemma3:12b/vmm/1907952 new file mode 100644 index 000000000..9c39fdce9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1907952 @@ -0,0 +1,45 @@ + +qemu-system-aarch64: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0 + +I originally observed this on Debian packaged qemu 5.2 at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 + +Today I checked out the latest git source at +Sun, 13 Dec 2020 19:21:09 +0900 +and configured the source as follows: + +./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu \ + --localstatedir=/var --disable-blobs --disable-strip --localstatedir=/var \ + --libdir=/usr/lib/aarch64-linux-gnu \ + --firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu \ + --target-list=aarch64-softmmu,arm-softmmu --disable-werror \ + --disable-user --enable-gtk --enable-vnc +then executed "make" on an ARM64 (not an x86_64) host, +running the latest Debian testing. + +I did the following commands on an arm64 host with the Debian Installer Alpha 3 at +https://cdimage.debian.org/cdimage/bullseye_di_alpha3/arm64/iso-cd/debian-bullseye-DI-alpha3-arm64-netinst.iso + +#!/bin/sh + +ARCH=arm64 +IMAGE=`pwd`/qemu-disk-${ARCH}.qcow2 +CDROM=`pwd`/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso +rm -f $IMAGE +qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o preallocation=off $IMAGE 20G +cd /var/tmp +cp /usr/share/AAVMF/AAVMF_VARS.fd . +$HOME/qemu-git/qemu/build/qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 3072 -smp 2\ + -net nic,model=virtio -net user -object rng-random,filename=/dev/urandom,id=rng0 \ + -device virtio-rng-pci,rng=rng0,id=rng-device0 \ + -drive if=virtio,file=${IMAGE},index=0,format=qcow2,discard=unmap,detect-zeroes=unmap,media=disk \ + -drive if=virtio,file=${CDROM},index=1,format=raw,readonly=on,media=cdrom \ + -drive if=pflash,format=raw,unit=0,file=/usr/share/AAVMF/AAVMF_CODE.fd,readonly=on \ + -drive if=pflash,format=raw,unit=1,file=`pwd`/AAVMF_VARS.fd + +Then 4 arrow keys on the physical keyboard are received as just "^[". + +This symptom was not observed on qemu-system-x86_64. +This symptom was not observed with virt-manager on my arm64 host, neither. +This seems unique to -display gtk of qemu-system-aarch64. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1908489 b/results/classifier/accel-gemma3:12b/vmm/1908489 new file mode 100644 index 000000000..71da3147e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1908489 @@ -0,0 +1,17 @@ + +qemu 4.2 bootloops with -cpu host and nested hypervisor + +I've noticed that after upgrading from Ubuntu 18.04 to 20.04 that nested virtualization isn't working anymore. + +I have a simple repro where I create a Windows 10 2004 guest and enable Hyper-V in it. This worked fine in 18.04 and specifically qemu <4.2 (I specifically tested Qemu 2.11-4.1 which work fine). + +The -cpu arg I'm passing is simply: + -cpu host,l3-cache=on,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + +Using that Windows won't boot because the nested hypervisor (Hyper-V) is unable to be initialize and so it just boot loops. Using the exact same qemu command works fine with 4.1 and lower. + +Switching to a named CPU model like Skylake-Client-noTSX-IBRS instead of host lets the VM boot but causes some weird behaviour later trying to use nested VMs. + +If I had to guess I think it would probably be related to this change https://github.com/qemu/qemu/commit/20a78b02d31534ae478779c2f2816c273601e869 which would line up with 4.2 being the first bad version but unsure. + +For now I just have to keep an older build of QEMU to work around this. Let me know if there's anything else needed. I can also try out any patches. I already have at least a dozen copies of qemu lying around now. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1911797 b/results/classifier/accel-gemma3:12b/vmm/1911797 new file mode 100644 index 000000000..df3cf33e1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1911797 @@ -0,0 +1,9 @@ + +hmp command `hostfwd_remove` does not work on running vm + +On a running VM, I ran the following two hmp commands: + +"hostfwd_add tcp::43210-:43210" --> WORKS +'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' + +QEMU version 5.1 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1913505 b/results/classifier/accel-gemma3:12b/vmm/1913505 new file mode 100644 index 000000000..7e362a32d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1913873 b/results/classifier/accel-gemma3:12b/vmm/1913873 new file mode 100644 index 000000000..a034c0d46 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1913873 @@ -0,0 +1,56 @@ + +QEMU: net: vmxnet: integer overflow may crash guest + +* Gaoning Pan from Zhejiang University & Ant Security Light-Year Lab reported a malloc failure + issue locates in vmxnet3_activate_device() of qemu/hw/net/vmxnet3.c NIC emulator + +* This issue is reproducible because while activating the NIC device, vmxnet3_activate_device + does not validate guest supplied configuration values against predefined min/max limits. + +@@ -1420,6 +1420,7 @@ static void vmxnet3_activate_device(VMXNET3State *s) + vmxnet3_setup_rx_filtering(s); + /* Cache fields from shared memory */ + s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); ++ assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); <= Did not check if MTU is within range + VMW_CFPRN("MTU is %u", s->mtu); + + s->max_rx_frags = +@@ -1473,6 +1474,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* Read rings memory locations for TX queues */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.txRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.txRingSize); ++ if (size > VMXNET3_TX_RING_MAX_SIZE) { <= Did not check TX ring size ++ size = VMXNET3_TX_RING_MAX_SIZE; ++ } + + vmxnet3_ring_init(d, &s->txq_descr[i].tx_ring, pa, size, + sizeof(struct Vmxnet3_TxDesc), false); +@@ -1483,6 +1487,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* TXC ring */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.compRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.compRingSize); ++ if (size > VMXNET3_TC_RING_MAX_SIZE) { <= Did not check TC ring size ++ size = VMXNET3_TC_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->txq_descr[i].comp_ring, pa, size, + sizeof(struct Vmxnet3_TxCompDesc), true); + VMXNET3_RING_DUMP(VMW_CFPRN, "TXC", i, &s->txq_descr[i].comp_ring); +@@ -1524,6 +1531,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* RX rings */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.rxRingBasePA[j]); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.rxRingSize[j]); ++ if (size > VMXNET3_RX_RING_MAX_SIZE) { <= Did not check RX ring size ++ size = VMXNET3_RX_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->rxq_descr[i].rx_ring[j], pa, size, + sizeof(struct Vmxnet3_RxDesc), false); + VMW_CFPRN("RX queue %d:%d: Base: %" PRIx64 ", Size: %d", +@@ -1533,6 +1543,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* RXC ring */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.compRingBasePA); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.compRingSize); ++ if (size > VMXNET3_RC_RING_MAX_SIZE) { <= Did not check RC ring size ++ size = VMXNET3_RC_RING_MAX_SIZE; ++ } + +This may lead to potential integer overflow OR OOB buffer access issues. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1913923 b/results/classifier/accel-gemma3:12b/vmm/1913923 new file mode 100644 index 000000000..fcb94f159 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1913923 @@ -0,0 +1,55 @@ + +assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach + +Hello, + +I found an assertion failure in hw/net/vmxnet3.c:1793 + +This was found in latest version 5.2.0. + +my reproduced is as follows: + + +cat << EOF | ./qemu-system-x86_64 \ +-device vmxnet3 \ +-display none -nodefaults -qtest stdio +outl 0xcf8 0x80001014 +outl 0xcfc 0xf0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +writel 0x5c000 0xbabefee1 +writel 0x5c028 0x5d000 +writel 0x5c03c 0x01010101 +writel 0x5d038 0xe0000000 +writel 0xf0001038 1 +EOF + + +Backtrace is as follows: +#0 0x00007f6f641a5f47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f6f641a78b1 in __GI_abort () at abort.c:79 +#2 0x00007f6f67922315 in g_assertion_message () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x00007f6f6792237a in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#4 0x000055edcaec96af in vmxnet3_io_bar1_write (opaque=0x628000004100, addr=56, val=1, size=4) at ../hw/net/vmxnet3.c:1793 +#5 0x000055edcbd294c6 in memory_region_write_accessor (mr=0x628000006b00, addr=56, value=0x7fffd52ba848, size=4, shift=0, mask=4294967295, attrs=...) at ../softmmu/memory.c:491 +#6 0x000055edcbd299be in access_with_adjusted_size (addr=56, value=0x7fffd52ba848, size=4, access_size_min=4, access_size_max=4, access_fn=0x55edcbd2918c <memory_region_write_accessor>, mr=0x628000006b00, attrs=...) at ../softmmu/memory.c:552 +#7 0x000055edcbd35ef2 in memory_region_dispatch_write (mr=0x628000006b00, addr=56, data=1, op=MO_32, attrs=...) at ../softmmu/memory.c:1501 +#8 0x000055edcba1e554 in flatview_write_continue (fv=0x6060000619a0, addr=4026535992, attrs=..., ptr=0x7fffd52bae80, len=4, addr1=56, l=4, mr=0x628000006b00) at ../softmmu/physmem.c:2759 +#9 0x000055edcba1e8c5 in flatview_write (fv=0x6060000619a0, addr=4026535992, attrs=..., buf=0x7fffd52bae80, len=4) at ../softmmu/physmem.c:2799 +#10 0x000055edcba1f391 in address_space_write (as=0x608000002620, addr=4026535992, attrs=..., buf=0x7fffd52bae80, len=4) at ../softmmu/physmem.c:2891 +#11 0x000055edcbaff8d3 in qtest_process_command (chr=0x55edd03ff4a0 <qtest_chr>, words=0x60300007f450) at ../softmmu/qtest.c:534 +#12 0x000055edcbb04aa1 in qtest_process_inbuf (chr=0x55edd03ff4a0 <qtest_chr>, inbuf=0x61900000fd00) at ../softmmu/qtest.c:797 +#13 0x000055edcbb04bcc in qtest_read (opaque=0x55edd03ff4a0 <qtest_chr>, buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 0xe0000"..., size=225) at ../softmmu/qtest.c:809 +#14 0x000055edcbe73742 in qemu_chr_be_write_impl (s=0x60f000002110, buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 0xe0000"..., len=225) at ../chardev/char.c:201 +#15 0x000055edcbe73820 in qemu_chr_be_write (s=0x60f000002110, buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 0xe0000"..., len=225) at ../chardev/char.c:213 +#16 0x000055edcbe9188e in fd_chr_read (chan=0x608000002520, cond=(G_IO_IN | G_IO_HUP), opaque=0x60f000002110) at ../chardev/char-fd.c:68 +#17 0x000055edcbe2379d in qio_channel_fd_source_dispatch (source=0x60c000025c00, callback=0x55edcbe915ac <fd_chr_read>, user_data=0x60f000002110) at ../io/channel-watch.c:84 +#18 0x00007f6f678fb285 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#19 0x000055edcc50b503 in glib_pollfds_poll () at ../util/main-loop.c:221 +#20 0x000055edcc50b68b in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +#21 0x000055edcc50b9a5 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#22 0x000055edcbd8805b in qemu_main_loop () at ../softmmu/vl.c:1678 +#23 0x000055edcab67e69 in main (argc=8, argv=0x7fffd52bd1d8, envp=0x7fffd52bd220) at ../softmmu/main.c:50 +#24 0x00007f6f64188b97 in __libc_start_main (main=0x55edcab67e2a <main>, argc=8, argv=0x7fffd52bd1d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffd52bd1c8) at ../csu/libc-start.c:310 +#25 0x000055edcab67d4a in _start () \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1913969 b/results/classifier/accel-gemma3:12b/vmm/1913969 new file mode 100644 index 000000000..aa7fc2353 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1913969 @@ -0,0 +1,24 @@ + +unable to migrate non shared storage when TLS is used + +Operating system: Gentoo +Architecture: x86_64 +kernel version: 5.4.72, 5.10.11 +libvirt version: at least 6.9.0, 6.10.0, 7.0.0 +Hypervisor and version: qemu 5.1.0, 5.2.0 + +With software versions described above and following configurations: +libvirt: +key_file = "/etc/ssl/libvirt/server.lan.key" +cert_file = "/etc/ssl/libvirt/server.lan.crt" +ca_file = "/etc/ssl/libvirt/ca.crt" +log_filters="3:remote 4:event 3:util.json 3:rpc 1:*" +log_outputs="1:file:/var/log/libvirt/libvirtd.log" +qemu: +default_tls_x509_cert_dir = "/etc/ssl/qemu" +default_tls_x509_verify = 1 +migration with tls: +virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource --copy-storage-all --verbose --tls +never succeeds. Progress stops typically at high progress amounts (95%-98%), and network traffic drastically drops as well (from 1 gbps+ to nothing). domjobinfo progress also stops. Without --tls migrations succeed without issues without any other changes to hosts or configurations. + +Note: I reported this originally as libvirt bug: https://gitlab.com/libvirt/libvirt/-/issues/108. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1914117 b/results/classifier/accel-gemma3:12b/vmm/1914117 new file mode 100644 index 000000000..d307ab138 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1914117 @@ -0,0 +1,16 @@ + +Short files returned via FTP on Qemu with various architectures and OSes + + +Qemu 5.2 on Mac OS X Big Sur. + +I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +Still getting the same problem,. + +On the following architectures: +arm64, amd64 and sometimes i386 running NetBSD host OS; +i386 running OpenBSD host OS: + +I have seen a consistent problem with FTP returning short files. The file will be a couple of bytes too short. I do not believe this is a problem with the OS. Downloading the perl source code from CPAN does not work properly, nor does downloading bind from isc. I've tried this on different architectures as above. + +(Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My gut feel is there is something not right on the Mac OS version of Qemu or a bug in 5.2 - obviously in the network layer somewhere. If you have anything you want me to try, please let me know - happy to help get a resolution.) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1914282 b/results/classifier/accel-gemma3:12b/vmm/1914282 new file mode 100644 index 000000000..25454df1c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1914282 @@ -0,0 +1,73 @@ + +block copy job sometimes hangs on the last block for minutes + +In openstack nova we use the block copy API to copy disks for volume swap requests. In our CI gate we observed that sometimes the block copy job progress will reach the last or next to last block and hang there for several minutes at a time, causing CI jobs to fail as jobs timeout. + +On the client (nova-compute) side, using the python bindings we see the following in the openstack nova logs: + +--------------- + +Jan 21 05:31:02.207785 ubuntu-focal-vexxhost-ca-ymq-1-0022641000 nova-compute[93823]: DEBUG nova.virt.libvirt.guest [None req-d6170fbb-e023-4cdb-93dc-a2e9ae9b0a56 tempest-TestVolumeSwap-1117975117 tempest-TestVolumeSwap-1117975117] COPY block job progress, current cursor: 0 final cursor: 1073741824 {{(pid=93823) is_job_complete /opt/stack/nova/nova/virt/libvirt/guest.py:873}} + +Jan 21 05:31:55.688227 ubuntu-focal-vexxhost-ca-ymq-1-0022641000 nova-compute[93823]: DEBUG nova.virt.libvirt.guest [None req-d6170fbb-e023-4cdb-93dc-a2e9ae9b0a56 tempest-TestVolumeSwap-1117975117 tempest-TestVolumeSwap-1117975117] COPY block job progress, current cursor: 1049624576 final cursor: 1073741824 {{(pid=93823) is_job_complete /opt/stack/nova/nova/virt/libvirt/guest.py:873}} + +[...] + +Jan 21 05:31:55.706698 ubuntu-focal-vexxhost-ca-ymq-1-0022641000 nova-compute[93823]: DEBUG nova.virt.libvirt.guest [None req-d6170fbb-e023-4cdb-93dc-a2e9ae9b0a56 tempest-TestVolumeSwap-1117975117 tempest-TestVolumeSwap-1117975117] COPY block job progress, current cursor: 1049624576 final cursor: 1073741824 {{(pid=93823) is_job_complete /opt/stack/nova/nova/virt/libvirt/guest.py:873}} + +Jan 21 05:31:56.175248 ubuntu-focal-vexxhost-ca-ymq-1-0022641000 nova-compute[93823]: DEBUG nova.virt.libvirt.guest [None req-d6170fbb-e023-4cdb-93dc-a2e9ae9b0a56 tempest-TestVolumeSwap-1117975117 tempest-TestVolumeSwap-1117975117] COPY block job progress, current cursor: 1073741823 final cursor: 1073741824 {{(pid=93823) is_job_complete /opt/stack/nova/nova/virt/libvirt/guest.py:873}} + +[...] + +~2.5 minutes later, it's still going at current cursor: 1073741823 final cursor: 1073741824 + +Jan 21 05:34:30.952371 ubuntu-focal-vexxhost-ca-ymq-1-0022641000 nova-compute[93823]: DEBUG nova.virt.libvirt.guest [None req-d6170fbb-e023-4cdb-93dc-a2e9ae9b0a56 tempest-TestVolumeSwap-1117975117 tempest-TestVolumeSwap-1117975117] COPY block job progress, current cursor: 1073741823 final cursor: 1073741824 {{(pid=93823) is_job_complete /opt/stack/nova/nova/virt/libvirt/guest.py:873}} + +then current cursor == final cursor at 05:34:31.460595 + +Jan 21 05:34:31.460595 ubuntu-focal-vexxhost-ca-ymq-1-0022641000 nova-compute[93823]: DEBUG nova.virt.libvirt.guest [None req-d6170fbb-e023-4cdb-93dc-a2e9ae9b0a56 tempest-TestVolumeSwap-1117975117 tempest-TestVolumeSwap-1117975117] COPY block job progress, current cursor: 1073741824 final cursor: 1073741824 {{(pid=93823) is_job_complete /opt/stack/nova/nova/virt/libvirt/guest.py:873}} + +--------------- + +In this excerpt the cursor reaches the next to last block at Jan 21 05:31:56.175248 and hangs there repeating status at the next to last block until Jan 21 05:34:30.952371 (~2.5 minutes) and then the job shows current cursor == final cursor at Jan 21 05:34:31.460595. + +In the corresponding qemu log, we see the block copy job report being on the last block for minutes: + +--------------- + +021-01-21 05:31:02.206+0000: 60630: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"return": [{"auto-finalize": true, "io-status": "ok", "device": "copy-vdb-libvirt-5-format", "auto-dismiss": false, "busy": true, "len": 1073741824, "offset": 0, "status": "running", "paused": false, "speed": 0, "ready": false, "type": "mirror"}], "id": "libvirt-501"}] +2021-01-21 05:31:02.206+0000: 60630: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7fd07813ec80 reply={"return": [{"auto-finalize": true, "io-status": "ok", "device": "copy-vdb-libvirt-5-format", "auto-dismiss": false, "busy": true, "len": 1073741824, "offset": 0, "status": "running", "paused": false, "speed": 0, "ready": false, "type": "mirror"}], "id": "libvirt-501"} + +[...] + +len == offset at 05:31:56.174 + +2021-01-21 05:31:56.174+0000: 60630: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"return": [{"auto-finalize": true, "io-status": "ok", "device": "copy-vdb-libvirt-5-format", "auto-dismiss": false, "busy": true, "len": 1073741824, "offset": 1073741824, "status": "running", "paused": false, "speed": 0, "ready": false, "type": "mirror"}], "id": "libvirt-581"}] +2021-01-21 05:31:56.174+0000: 60630: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7fd07813ec80 reply={"return": [{"auto-finalize": true, "io-status": "ok", "device": "copy-vdb-libvirt-5-format", "auto-dismiss": false, "busy": true, "len": 1073741824, "offset": 1073741824, "status": "running", "paused": false, "speed": 0, "ready": false, "type": "mirror"}], "id": "libvirt-581"} + +[...] + +~2.5 minutes later, still len == offset but it's still going + +2021-01-21 05:34:31.459+0000: 60630: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"return": [{"auto-finalize": true, "io-status": "ok", "device": "copy-vdb-libvirt-5-format", "auto-dismiss": false, "busy": false, "len": 1073741824, "offset": 1073741824, "status": "ready", "paused": false, "speed": 0, "ready": true, "type": "mirror"}], "id": "libvirt-855"}] +2021-01-21 05:34:31.459+0000: 60630: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7fd07813ec80 reply={"return": [{"auto-finalize": true, "io-status": "ok", "device": "copy-vdb-libvirt-5-format", "auto-dismiss": false, "busy": false, "len": 1073741824, "offset": 1073741824, "status": "ready", "paused": false, "speed": 0, "ready": true, "type": "mirror"}], "id": "libvirt-855"} + +and then the job finishes soon after + +2021-01-21 05:34:31.467+0000: 60630: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-5-format'(domain: 0x7fd070075720,instance-00000013) state changed to 'waiting'(6) + +2021-01-21 05:34:31.467+0000: 60630: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-5-format'(domain: 0x7fd070075720,instance-00000013) state changed to 'pending'(7) + +2021-01-21 05:34:31.467+0000: 60630: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-5-format'(domain: 0x7fd070075720,instance-00000013) state changed to 'concluded'(9) + +2021-01-21 05:34:31.468+0000: 60630: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-5-format'(domain: 0x7fd070075720,instance-00000013) state changed to 'null'(11) + +2021-01-21 05:34:31.468+0000: 60634: debug : qemuBlockJobProcessEventConcludedCopyPivot:1221 : copy job 'copy-vdb-libvirt-5-format' on VM 'instance-00000013' pivoted + +2021-01-21 05:34:32.292+0000: 60634: debug : qemuDomainObjEndJob:9746 : Stopping job: modify (async=none vm=0x7fd070075720 name=instance-00000013) + +--------------- + +Is this normal for a block copy job to hang on the last block like this for minutes at a time? Why doesn't the job close out once offset == len? + +Thanks for any help you can offer. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1915431 b/results/classifier/accel-gemma3:12b/vmm/1915431 new file mode 100644 index 000000000..c7ab3dc30 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1915431 @@ -0,0 +1,12 @@ + +QEMU processes started by Acceptance Tests are left running + +Every now and then, QEMU processes started by the Acceptance Tests (thus by Avocado) will be left running. + +From Avocado's perspective, when everything "goes well" and a test reaches completion, there's no attempt to terminate any processes it indirectly started. Some frameworks and tests built on top of Avocado, for instance Avocado-VT, will keep processes running between various tests. + +When a job (and consequently a test) is manually interrupted, then Avocado tries to terminate the entire process tree. + +It may be possible to improve the situation in which, at the very least, the user is: + * notified of left over processes + * have a configuration option that will attempt to kill all processes at the end of the test execution \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1916506 b/results/classifier/accel-gemma3:12b/vmm/1916506 new file mode 100644 index 000000000..bd3645fa9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1916506 @@ -0,0 +1,17 @@ + +make check-venv may leave stale and incomplete tests/venv directory directory + +As reported by "Philippe Mathieu-Daudé" <email address hidden>, a "make check-venv" can be run and fail to properly create a suitable virtual environment, leaving the tests/venv directory which is the target for "make check-venv" itself. + +This means that on a subsequent run: + +> $ make check-venv +> GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3 +> tests/fp/berkeley-softfloat-3 dtc capstone slirp +> make: Nothing to be done for 'check-venv'. + +And the venv will still be incomplete. The causes of such failures to create a suitable virtual environment are too many (in the reported case it was because of missing *required* Python packages). Some more evolved virtual environments + Python packaging systems exist that could probably be used here (Pipenv) but would add further core requirements. + +The current mitigation is to run "make check-clean" when the venv appears to be incomplete. + +The goal of this bug is to attempt to make the venv setup atomic and more reliable. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1920013 b/results/classifier/accel-gemma3:12b/vmm/1920013 new file mode 100644 index 000000000..6ce87a40c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1920013 @@ -0,0 +1,20 @@ + +Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest + +Attempting to pass through a PCIe device from a ppc64le host to an x86_64 guest with QEMU v5.2.0-3031-g571d413b5d (built from git master) fails with the following error: + + include/exec/memory.h:43:IOMMU_MEMORY_REGION: Object 0x10438eb00 is not an instance of type qemu:iommu-memory-region + +To reproduce this issue, simply run the following command on a POWER9 system: + + qemu-system-x86_64 -machine q35 -device vfio-pci,host=$DBSF + +Where $DBSF is a domain:bus:slot.function PCIe device address. + +This also fails with QEMU 3.1.0 (from Debian Buster), so I assume this has never worked. Helpfully, the error message it prints seems to indicate where the problem is: + + hw/vfio/spapr.c:147:vfio_spapr_create_window: Object 0x164473510 is not an instance of type qemu:iommu-memory-region + +My kernel (Linux v5.8.0 plus some small unrelated patches) is built with the page size set to 4k, so this issue shouldn't be due to a page size mismatch. And as I stated earlier, my host arch is ppc64le, so it shouldn't be an endianness issue, either. + +I assume this should be possible (in theory) since I've seen reports of others getting PCIe passthrough working with aarch64 guests on x86_64 hosts, but of course that (passthrough to weird guest arch on x86) is somewhat the opposite of what I'm trying to do (passthrough to x86 on weird host arch) so I don't know for sure. If it is possible, I'm willing to develop a fix myself, but I'm almost completely unfamiliar with QEMU's internals so if anyone has any advice on where to start I'd greatly appreciate it. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1920871 b/results/classifier/accel-gemma3:12b/vmm/1920871 new file mode 100644 index 000000000..9c3ea14ed --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1920871 @@ -0,0 +1,52 @@ + +netperf UDP_STREAM high packet loss on QEMU tap network + +Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output: + +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 144710 0 7583.56 +212992 10.00 32 1.68 + +We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,xxxxx". I can got: +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 18351 0 961.61 +212992 10.00 18350 961.56 + +most of UDP packets are recived. + +And If we check the tap qemu used, we can see: +ifconfig tap0 +tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 + inet6 fe80::ecc6:21ff:fe6f:b174 prefixlen 64 scopeid 0x20<link> + ether ee:c6:21:6f:b1:74 txqueuelen 1000 (Ethernet) + RX packets 282 bytes 30097 (29.3 KiB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 9086214 bytes 12731596673 (11.8 GiB) + TX errors 0 dropped 16349024 overruns 0 carrier 0 collisions 0 +lots of TX packets are dropped. + +list other packet size: + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 1 10.00 2297941 0 1.84 +212992 10.00 1462024 1.17 + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 128 10.00 2311547 0 236.70 +212992 10.00 1359834 139.25 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1921082 b/results/classifier/accel-gemma3:12b/vmm/1921082 new file mode 100644 index 000000000..dc135037e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1921082 @@ -0,0 +1,17 @@ + +VM crash when process broadcast MCE + +When i do memory SRAR test for VM, I meet the following issue: + +My VM has 16 vCPU, I will inject one UE error to memory which is accessed by VM, Then host MCE is raised and SIGBUS is send to VM, and qemu take control. +Qemu will check the broadcast attribute by following cpu_x86_support_mca_broadcast(); + +Then Qemu may inject MCE to all vCPU, as vCPU is just one process for HOST, we can't guarantee all the vCPUs will enter MCE hander in 1S sync time, and the VM may panic. + +This issue will be easily fixed by expand monarch_timeout configuration, but the exact monarch_timeout can't be easily got, as it will depand on the num of vCPUs and current system schedule status. + +I am wondering why VM need broadcast attribute for MCE, When qeme process MCE event form host, it will always be signaled for one vCPU? If so, why does qemu need boradcast the MCE event to all vCPUs? + +Can weu just deliver LMCE to one specifc vCPU and make this behavior default? + +If anything wrong, Please point out. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1921280 b/results/classifier/accel-gemma3:12b/vmm/1921280 new file mode 100644 index 000000000..7780f5b42 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1921280 @@ -0,0 +1,8 @@ + +OpenIndiana stuck in boot loop when using hvf + +I'm using QEMU version 5.2.0 on macOS, and running the "OpenIndiana Hipster 2020.10 Text Install DVD (64-bit x86)" ISO: + +qemu-system-x86_64 -cdrom ~/Downloads/OI-hipster-text-20201031.iso -m 2048 -accel hvf -cpu host + +It gets to "Booting...", stays there for a bit, and then restarts. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1922102 b/results/classifier/accel-gemma3:12b/vmm/1922102 new file mode 100644 index 000000000..e0c630252 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1922102 @@ -0,0 +1,48 @@ + +Broken tap networking on macOS host + +Building QEMU with GLib newer than 2.58.3 corrupts tap networking. +Tap device was provided by Tun/Tap kernel extension installed from brew: + brew install tuntap + +Checked revisions: + 553032d (v5.2.0) + 6d40ce0 (v6.0.0-rc1) + +Host: + MacBook Pro (Retina, 15-inch, Mid 2015) + macOS Catalina 10.15.6 (19G2021) + +Guest: + Linux Ubuntu 4.4.0-206-generic x86_64 + Also tested macOS Catalina 10.15.7 as a guest, the behaviour is the same. + +QEMU command line: + +qemu-system-x86_64 \ + -drive file=hdd.qcow2,if=virtio,format=qcow2 \ + -m 3G \ + -nic tap,script=tap-up.sh + +tap-up.sh: + + #!/bin/sh + + TAPDEV="$1" + BRIDGEDEV="bridge0" + + ifconfig "$BRIDGEDEV" addm "$TAPDEV" + +Enabling/disabling Hypervisor.Framework acceleration (`-accel hvf`) has no effect. + +How to reproduce: + 1. Build & install GLib > 2.58.3 (tested 2.60.7, 2.60.7) + 2. Build qemu-system-x86_64 with GLib > 2.58.3 + 3. Boot any guest any guest with tap networking enabled + 4. See that the external network is inaccessible + +Hotfix: + 1. Build & install GLib 2.58.3 + 2. Build qemu-system-x86_64 with GLib 2.58.3 + 3. Boot any guest with tap networking enabled + 4. See that the external network is accessible, everything is working as expected \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1923 b/results/classifier/accel-gemma3:12b/vmm/1923 new file mode 100644 index 000000000..caf094edd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1923 @@ -0,0 +1,19 @@ + +qemu breaks vmdk larger than 600GB. +Description of problem: +The vmdk larger than 600G is corrupted after an edit by qemu-nbd. If I open the corrupted vmdk file, I find an extra **^@** byte. +``` +RW 4194304 SPARSE "disk-s289.vmdk" +RW 4^@94304 SPARSE "disk-s290.vmdk" +RW 4194304 SPARSE "disk-s291.vmdk" +``` +Steps to reproduce: +``` + qemu-img create -f vmdk -o subformat=twoGbMaxExtentSparse disk.vmdk 1T + sudo qemu-nbd -c /dev/nbd0 disk.vmdk + sudo mkfs.btrfs /dev/nbd0 + sudo qemu-nbd -d /dev/nbd0 + qemu-img info disk.vmdk | head + ``` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1923583 b/results/classifier/accel-gemma3:12b/vmm/1923583 new file mode 100644 index 000000000..bc2f2aa2b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1923583 @@ -0,0 +1,38 @@ + +colo: pvm flush failed after svm killed + +Hi, + Primary vm flush failed after killing svm, which leads primary vm guest filesystem unavailable. + +qemu versoin: 5.2.0 +host/guest os: CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm (don't remove nbd child from quorum on primary vm)and wait for a minute. the interval depends on guest os. +result: primary vm file system shutdown because of flush cache error. + +After serveral tests, I found that qemu-5.0.0 worked well, and it's the commit https://git.qemu.org/?p=qemu.git;a=commit;h=883833e29cb800b4d92b5d4736252f4004885191(block: Flush all children in generic code) leads this change, and both virtio-blk and ide turned out to be bad. + +I think it's nbd(replication) flush failed leads bdrv_co_flush(quorum_bs) failed, here is the call stack. +#0 bdrv_co_flush (bs=0x56242b3cc0b0=nbd_bs) at ../block/io.c:2856 +#1 0x0000562428b0f399 in bdrv_co_flush (bs=0x56242b3c7e00=replication_bs) at ../block/io.c:2920 +#2 0x0000562428b0f399 in bdrv_co_flush (bs=0x56242a4ad800=quorum_bs) at ../block/io.c:2920 +#3 0x0000562428b70d56 in blk_do_flush (blk=0x56242a4ad4a0) at ../block/block-backend.c:1672 +#4 0x0000562428b70d87 in blk_aio_flush_entry (opaque=0x7fd0980073f0) at ../block/block-backend.c:1680 +#5 0x0000562428c5f9a7 in coroutine_trampoline (i0=-1409269904, i1=32721) at ../util/coroutine-ucontext.c:173 + +While i am not sure whether i use colo inproperly? Can we assume that nbd child of quorum immediately removed right after svm crashed? Or it's really a bug? Does the following patch fix? Help is needed! Thanks a lot！ + +diff --git a/block/quorum.c b/block/quorum.c +index cfc1436..f2c0805 100644 +--- a/block/quorum.c ++++ b/block/quorum.c +@@ -1279,7 +1279,7 @@ static BlockDriver bdrv_quorum = { + .bdrv_dirname = quorum_dirname, + .bdrv_co_block_status = quorum_co_block_status, + +- .bdrv_co_flush_to_disk = quorum_co_flush, ++ .bdrv_co_flush = quorum_co_flush, + + .bdrv_getlength = quorum_getlength, \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1923648 b/results/classifier/accel-gemma3:12b/vmm/1923648 new file mode 100644 index 000000000..ba5362bea --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/1923689 b/results/classifier/accel-gemma3:12b/vmm/1923689 new file mode 100644 index 000000000..1cb946b42 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1923689 @@ -0,0 +1,81 @@ + +sig-abort / coredump observed from aio_ctx_finalize + +Observing occasional sig-abort based on v5.2.0 (tag) of QEMU. The VMM is configured for Kata use case, launching with a nvdimm/pmem based rootfs, and a set of workloads which are heavily utilizing virtio-fs. + +Sample qemu-cmdline: +/usr/bin/qemu-kata-system-x86_64 +-name sandbox-9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c +-uuid cd58d78d-ad44-4d26-9eab-66efab3fb23b +-machine pc,accel=kvm,kernel_irqchip,nvdimm=on +-cpu host,pmu=off +-qmp unix:/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/qmp.sock,server,nowait +-m 2048M,slots=10,maxmem=386381M +-device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= +-device virtio-serial-pci,disable-modern=false,id=serial0,romfile=,max_ports=2 +-device virtconsole,chardev=charconsole0,id=console0 +-chardev socket,id=charconsole0,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/console.sock,server,nowait +-device nvdimm,id=nv0,memdev=mem0 +-object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers.img,size=536870912 +-object rng-random,id=rng0,filename=/dev/urandom +-device virtio-rng-pci,rng=rng0,romfile= +-device vhost-vsock-pci,disable-modern=false,vhostfd=3,id=vsock-3054067214,guest-cid=3054067214,romfile= +-chardev socket,id=char-770bb156466e8ed5,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/vhost-fs.sock +-device vhost-user-fs-pci,chardev=char-770bb156466e8ed5,tag=kataShared,romfile= +-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 +-device driver=virtio-net-pci,netdev=network-0,mac=9e:ad:0c:d1:58:e0,disable-modern=false,mq=on,vectors=4,romfile= +-rtc base=utc,driftfix=slew,clock=host +-global kvm-pit.lost_tick_policy=discard +-vga none +-no-user-config +-nodefaults +-nographic +--no-reboot +-daemonize +-object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +-numa node,memdev=dimm1 +-kernel /usr/share/kata-containers/vmlinuz +-append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=32 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket +-pidfile /run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/pid +-smp 1,cores=1,threads=1,sockets=32,maxcpus=32 + +From the core file I was able to obtain a backtrace: + +``` +(gdb) info thread + Id Target Id Frame + 6 Thread 0x7f92feffd700 (LWP 14678) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 5 Thread 0x7f92fffff700 (LWP 13860) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 4 Thread 0x7f930dcff700 (LWP 13572) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 3 Thread 0x7f92ff7fe700 (LWP 14179) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 2 Thread 0x7f93aed03700 (LWP 13565) 0x00007f93b20bfd19 in syscall () from /lib64/libc.so.6 +* 1 Thread 0x7f93c718dcc0 (LWP 13564) 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +(gdb) bt trace +No symbol table is loaded. Use the "file" command. +(gdb) bt +#0 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +#1 0x00007f93b1ffeac8 in abort () from /lib64/libc.so.6 +#2 0x00007f93b1ff61a6 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00007f93b1ff6252 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000007c6955 in aio_ctx_finalize () +#5 0x00007f93c64223d1 in g_source_unref_internal () from /lib64/libglib-2.0.so.0 +#6 0x00007f93c64225f5 in g_source_iter_next () from /lib64/libglib-2.0.so.0 +#7 0x00007f93c642362d in g_main_context_unref () from /lib64/libglib-2.0.so.0 +#8 0x00007f93c6425628 in g_main_loop_unref () from /lib64/libglib-2.0.so.0 +#9 0x00000000006dbaa0 in iothread_instance_finalize () +#10 0x00000000006c01e9 in object_unref () +#11 0x00000000006be647 in object_property_del_child () +#12 0x000000000075ad79 in monitor_cleanup () +#13 0x0000000000630635 in qemu_cleanup () +#14 0x000000000040fed3 in main () +``` + +I *think* we're hitting this assert: https://github.com/qemu/qemu/blob/master/util/async.c#L339 based on +``` +(gdb) up +#4 0x00000000007c6955 in aio_ctx_finalize () +``` + +The error is relatively infrequent, but a catastrophic core dump none the less. + +Please let me know if there's more I can pull from the core, or more info I can share to help facilitate debugging this error. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1923692 b/results/classifier/accel-gemma3:12b/vmm/1923692 new file mode 100644 index 000000000..cc9e798a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1923692 @@ -0,0 +1,8 @@ + +qemu 5.2.0: Add reconnect option support for netdev socket + +Most of qemu socket accepting options (such as chardev) accept among other things a "reconnect" option. + +netdev socket however returns: Invalid parameter 'reconnect' + +It would make sense that available options for socket links be at least partially normalized (also see issue https://bugs.launchpad.net/qemu/+bug/1903470 which was closed without resolution). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1924912 b/results/classifier/accel-gemma3:12b/vmm/1924912 new file mode 100644 index 000000000..7032d593d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1924912 @@ -0,0 +1,45 @@ + +VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash + +I ran SerenityOS <https://github.com/SerenityOS/serenity> out of WSL2 with native Windows QEMU. The system runs fine on the Linux QEMU (with Windows X-Server). However, with Windows QEMU I get a hard crash after the following output: + +``` +[#0 colonel(0:0)]: Scheduler[0]: idle loop running +[init_stage2(2:2)]: PCI [0000:00:00:00] PCI::ID [8086:1237] +[init_stage2(2:2)]: PCI [0000:00:01:00] PCI::ID [8086:7000] +[init_stage2(2:2)]: PCI [0000:00:01:01] PCI::ID [8086:7010] +[init_stage2(2:2)]: PCI [0000:00:01:02] PCI::ID [8086:7020] +[init_stage2(2:2)]: PCI [0000:00:01:03] PCI::ID [8086:7113] +[init_stage2(2:2)]: PCI [0000:00:02:00] PCI::ID [1234:1111] +[init_stage2(2:2)]: PCI [0000:00:03:00] PCI::ID [8086:2922] +[init_stage2(2:2)]: PCI [0000:00:04:00] PCI::ID [1af4:1003] +[init_stage2(2:2)]: PCI [0000:00:05:00] PCI::ID [1af4:1005] +[init_stage2(2:2)]: PCI [0000:00:06:00] PCI::ID [8086:100e] +[#0 init_stage2(2:2)]: BXVGA: framebuffer @ P0xf8000000 +[#0 init_stage2(2:2)]: BXVGADevice resolution set to 1024x768 (pitch=4096) +[init_stage2(2:2)]: UHCI: Controller found PCI::ID [8086:7020] @ PCI [0000:00:01:02] +[init_stage2(2:2)]: UHCI: I/O base IO c080 +[init_stage2(2:2)]: UHCI: Interrupt line: 11 +[#0 init_stage2(2:2)]: UHCI: Allocated framelist at physical address P0x00e40000 +[#0 init_stage2(2:2)]: UHCI: Framelist is at virtual address V0xc115d000 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f000) @ 14946304: link_ptr=14946338, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f020) @ 14946336: link_ptr=14946370, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f040) @ 14946368: link_ptr=14946402, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f060) @ 14946400: link_ptr=14946434, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f080) @ 14946432: link_ptr=14958593, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: Reset completed +[#0 init_stage2(2:2)]: UHCI: Started +[#0 init_stage2(2:2)]: DMIExpose: SMBIOS 32bit Entry point @ P0x000f5870 +[#0 init_stage2(2:2)]: DMIExpose: Data table @ P0x000f5890 +[#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00] +[#0 init_stage2(2:2)]: Trying to unregister unused handler (?) +[#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported! +[#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0 +qemu-system-i386.exe: warning: GLib: Too many handles to wait for! +``` + +The lines starting with [ are SerenityOS output; QEMU warns "GLib: Too many handles to wait for!" and crashes right after (can't even Ctrl-C in the WSL command line, force-close in Windows necessary). A window is still spawned but as the OS already switched out of text mode, just a black screen is visible as QEMU crashes. + +I first thought this to be an issue with SerenityOS and reported it over there: <https://github.com/SerenityOS/serenity/issues/6422>. The kernel devs pointed out that this seems to be a VirtIO driver/device issue on the Windows build of QEMU, because the Serenity kernel tries to initialize VirtIO devices which apparently crashes QEMU. There will be mitigations from the SerenityOS side (by allowing to disable VirtIO on boot) but it would of course be great if QEMU handled this properly. + +Version info: Both QEMU 6.0.0-rc3 and 5.2.0 exhibit this issue. Windows release is 20H2, WSL2 is running Debian 10.9. SerenityOS has no proper version but it was reproduced on the most current commits as of 18/04/2021. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1924987 b/results/classifier/accel-gemma3:12b/vmm/1924987 new file mode 100644 index 000000000..4421959d0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1924987 @@ -0,0 +1,13 @@ + +Storage | Two decimal digits precision + +Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64 + +Hello. A two decimal digits precision is most appropriated on systems whose storage capacities have to be saved. That is one of the reason why such precision is supported in the context of creation of virtual machines in several Unix/Linux virtualization platforms; virt-manager is one of them. That last exhibits virtual disks size values with such precision – 128.00 GiB – nevertheless it lacks yet a mention illustrating physical disks size values. + +Storage values exhibited in qemu-img and virt-manager are already according to a clear format; thus, values are not attached to their measure units (#value# #units#). + +$ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n '2,4p' +file format: qcow2 +virtual size: 128 GiB (137438953472 bytes) +disk size: 147 MiB \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1925109 b/results/classifier/accel-gemma3:12b/vmm/1925109 new file mode 100644 index 000000000..3c63a8844 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1925109 @@ -0,0 +1,18 @@ + +usbredirparser: bulk transfer length exceeds limits + +2021-04-20T01:26:36.662244Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:26:36.662276Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +2021-04-20T01:26:57.670412Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:26:57.670445Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +2021-04-20T01:37:01.920613Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:37:01.920624Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +host: +Linux version 5.11.15-arch1-2 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 +guest: +win10 20H2 +usb device: +Bus 002 Device 007: ID 0781:55ab SanDisk Corp. SanDisk 3.2Gen1 +size 250G + +https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirparser/usbredirparser.c#L32 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1925496 b/results/classifier/accel-gemma3:12b/vmm/1925496 new file mode 100644 index 000000000..9c2e8616c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1925496 @@ -0,0 +1,65 @@ + +nvme disk cannot be hotplugged after removal + +Hello, + +When I try to re-add an nvme disk shortly after removing it, I get an error about duplicate ID. + +See the following commands to reproduce. This happens consistently on all VMs that I tested: + + +attach +========== + +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; +$VAR1 = { + 'execute' => 'device_add', + 'arguments' => { + 'serial' => 'nvme1', + 'drive' => 'drive-nvme1', + 'driver' => 'nvme', + 'id' => 'nvme1' + } + }; + + +detach +=========== +$VAR1 = { + 'arguments' => { + 'id' => 'nvme1' + }, + 'execute' => 'device_del' + }; +$VAR1 = { + 'execute' => 'human-monitor-command', + 'arguments' => { + 'command-line' => 'drive_del drive-nvme1' + } + }; + +reattach +=========== +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; + + +and I get: +"Duplicate ID 'drive-nvme1' for drive" + +although it does not show up in query-block or query-pci anymore after the first detach. + + +Is this a bug or am I missing something? Please advise. + +Best regards, +Oguz \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1926 b/results/classifier/accel-gemma3:12b/vmm/1926 new file mode 100644 index 000000000..82a83dbcf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1926 @@ -0,0 +1,25 @@ + +Spice: handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed (DoS via assert failure) +Description of problem: +Assert failure in libspice-server was found during fuzzing qxl-vga device. + +```plaintext +qemu-system-x86_64: Spice: ../server/red-worker.cpp:367:handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed +Аварийный останов +``` +Steps to reproduce: +1. This bug can be reroduced with + + ```plaintext + cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M \ + pc -nodefaults -vga qxl -qtest stdio + outl 0xcf8 0x8000101c + outl 0xcfc 0xc000 + outl 0xcf8 0x80001004 + outw 0xcfc 0x01 + outl 0xc00b 0x01000000 + EOF + ``` +2. This bug is in another place from https://gitlab.com/qemu-project/qemu/-/issues/1829, please pay attention to it. It has to be solved, because it interferes with further fuzzing process +Additional information: +As I mentioned, I really need this bug to be solved, because fuzzing qxl-vga device gets less efficient. I suggested to report it here, not in spice-server, because this bug can be on the QEMU side. diff --git a/results/classifier/accel-gemma3:12b/vmm/1926052 b/results/classifier/accel-gemma3:12b/vmm/1926052 new file mode 100644 index 000000000..203b38b98 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1926052 @@ -0,0 +1,16 @@ + +qemu freezes during grub on arch cloudimg + +When booting the Arch Linux cloud image and setting `-nographic`, qemu will freeze during the grub bootloader. +Tested with qemu 5.1 and 5.2. + +Reproduce: +``` +wget https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/20342/artifacts/raw/output/Arch-Linux-x86_64-basic-20210420.20342.qcow2 + +qemu-system-x86_64 -hda Arch-Linux-x86_64-basic-20210420.20342.qcow2 -nographic + +``` + +It will get stuck while displaying `Welcome to GRUB!` +If -nographic is omitted, it will continue to boot (without any keyboard interaction) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1926111 b/results/classifier/accel-gemma3:12b/vmm/1926111 new file mode 100644 index 000000000..ce2fcfe95 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1926111 @@ -0,0 +1,86 @@ + +Assertion `tx_queue_idx <= s->txq_num' failed in vmxnet3_io_bar0_write + +=== Stacktrace === + +qemu-fuzz-i386: ../hw/net/vmxnet3.c:1096: void vmxnet3_io_bar0_write(void *, hwaddr, uint64_t, unsigned int): Assertion `tx_queue_idx <= s->txq_num' failed. +==602353== ERROR: libFuzzer: deadly signal +#5 0x7fe4b93a7ce0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7fe4b9391536 in abort stdlib/abort.c:79:7 +#7 0x7fe4b939140e in __assert_fail_base assert/assert.c:92:3 +#8 0x7fe4b93a0661 in __assert_fail assert/assert.c:101:3 +#9 0x563e6cf5ebb5 in vmxnet3_io_bar0_write hw/net/vmxnet3.c:1096:9 +#10 0x563e6eefdb00 in memory_region_write_accessor softmmu/memory.c:491:5 +#11 0x563e6eefcfdd in access_with_adjusted_size softmmu/memory.c:552:18 +#12 0x563e6eefac90 in memory_region_dispatch_write softmmu/memory.c:1502:16 +#13 0x563e6e834e16 in flatview_write_continue softmmu/physmem.c:2746:23 +#14 0x563e6e81cd38 in flatview_write softmmu/physmem.c:2786:14 +#15 0x563e6e81c868 in address_space_write softmmu/physmem.c:2878:18 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -machine q35 -nodefaults -device vmxnet3,netdev=net0 -netdev \ +user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000814 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xcf8 0x80000815 +outl 0xcfc 0xffff00b5 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0xff00b020 0x4 0x0000feca +write 0xe0000630 0x1 0x00 +EOF + + +=== Testcase === + +/* + * Autogenerated Fuzzer Test Case + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +static void test_fuzz(void) { + QTestState *s = qtest_init(" -display none , -m 512M -machine q35 -nodefaults " + "-device vmxnet3,netdev=net0 -netdev user,id=net0"); + qtest_outl(s, 0xcf8, 0x80000810); + qtest_outl(s, 0xcfc, 0xe0000000); + qtest_outl(s, 0xcf8, 0x80000814); + qtest_outl(s, 0xcf8, 0x80000804); + qtest_outw(s, 0xcfc, 0x7); + qtest_outl(s, 0xcf8, 0x80000815); + qtest_outl(s, 0xcfc, 0xffff00b5); + qtest_bufwrite(s, 0x0, "\xe1", 0x1); + qtest_bufwrite(s, 0x1, "\xfe", 0x1); + qtest_bufwrite(s, 0x2, "\xbe", 0x1); + qtest_bufwrite(s, 0x3, "\xba", 0x1); + qtest_bufwrite(s, 0xff00b020, "\x00\x00\xfe\xca", 0x4); + qtest_bufwrite(s, 0xe0000630, "\x00", 0x1); + qtest_quit(s); +} +int main(int argc, char **argv) { + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + +=== OSS-Fuzz Report === +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33603 +https://oss-fuzz.com/testcase?key=6071483232288768 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1926995 b/results/classifier/accel-gemma3:12b/vmm/1926995 new file mode 100644 index 000000000..1e9f7091c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1926995 @@ -0,0 +1,19 @@ + +hw/remote/mpqemu-link.c:221: bad error checking ? + +hw/remote/mpqemu-link.c:221:36: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op] + +Source code is + + if (msg->cmd >= MPQEMU_CMD_MAX && msg->cmd < 0) { + return false; + } + +Maybe better code: + + if (msg->cmd >= MPQEMU_CMD_MAX || msg->cmd < 0) { + return false; + } + +It might be useful to switch on gcc compiler flag -Wlogical-op +to see these warnings. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/1931 b/results/classifier/accel-gemma3:12b/vmm/1931 new file mode 100644 index 000000000..98c2fb992 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1931 @@ -0,0 +1,4 @@ + +dbus: Support multiple QEMU instances +Additional information: +cc @marcandre.lureau diff --git a/results/classifier/accel-gemma3:12b/vmm/1932 b/results/classifier/accel-gemma3:12b/vmm/1932 new file mode 100644 index 000000000..8fd6e95a0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1932 @@ -0,0 +1,13 @@ + +Broken grab on hover setting +Description of problem: +It seems that now qemu implements "static" grab on hover, i.e., it can only be disabled by + +1. setting `vmport=off` in `-M` (btw, `pc` or `q35`, doesn't matter) +2. emulating a usb mouse *and* blacklist/unload the `psmouse` driver on the guest side + +while grab on hover setting in the gtk display backend (or frontend?) is seemingly bogus now either way. + +Can this be fixed (again?) so that the setting (which can be toggled in the menu "dynamically") can be used to tell this "vmport" thing whether or not it should grab on hover? +Additional information: +NIL diff --git a/results/classifier/accel-gemma3:12b/vmm/1939 b/results/classifier/accel-gemma3:12b/vmm/1939 new file mode 100644 index 000000000..7369143ab --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1939 @@ -0,0 +1,65 @@ + +qemu master git can no longer be compiled under MacOs Sonoma 14.0 +Description of problem: + +Steps to reproduce: +Qemu master git fails to compile under MacOs M1/2, I already tested it with "git-bisect" "git bisect good" and "git bisect bad".All dependencies for qemu are fulfilled and were installed using Homebrew under MacOs.It fails with these commits: + + +`>>>>> commit 7c3fb52bcdaef85b15a91b3ca4d1516f9d9b5402 +>>>>> Author: Paolo Bonzini <pbonzini@redhat.com> +>>>>> Date: Tue Aug 8 20:28:25 2023 +0200 +>>>>> +>>>>> configure: never use PyPI for Meson +>>>>> +>>>>> Since there is a vendored copy, there is no point in choosing +>> online +>>>> +>>>>> operation. +>>>>> +>>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +>> +>>>>> +>>>>> configure | 6 ------ +>>>>> 1 file changed, 6 deletions(-) +>>>>>` +Additional information: +Older sources Qemu 8.1 can be compiled without problems. The only thing that has changed is that I did a major system update and Xcode was also updated. Since then compiling on qemu master version 8.1.50 breaks. + +``` +`On branch master +Your branch is up to date with 'origin/master'. + +nothing to commit, working tree clean +Mac-Studio qemu % ./configure --target-list=ppc-softmmu +Using './build' as the directory for build output +python determined to be '/Library/Frameworks/Python.framework/Versions/3.10/bin/python3' +python version: Python 3.10.8 +mkvenv: Creating non-isolated virtual environment at 'pyvenv' +mkvenv: checking for tomli>=1.2.0 +mkvenv: installing tomli>=1.2.0 +mkvenv: checking for meson>=0.63.0 +mkvenv: installing meson==0.63.3 +mkvenv: checking for sphinx>=1.6 +mkvenv: checking for sphinx_rtd_theme>=0.5 + +'sphinx==5.3.0' not found: +• Python package 'sphinx' was not found nor installed. +• mkvenv was configured to operate offline and did not check PyPI. + + +Sphinx not found/usable, disabling docs. +Disabling PIE due to missing toolchain support +The Meson build system +Version: 0.63.3 +Source dir: /Users/qemu +Build dir: /Users/qemu/build +Build type: native build +Project name: qemu +Project version: 8.1.50 + +../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -Wl,--version` +stdout: +stderr: ld: unknown options: --version +clang: error: linker command failed with exit code 1 (use -v to see invocation)` +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1939179 b/results/classifier/accel-gemma3:12b/vmm/1939179 new file mode 100644 index 000000000..31905b273 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1939179 @@ -0,0 +1,22 @@ + +qemu-ga fsfreeze crashes the kernel + +Hello, + +Still required your attention, duplicate from: +https://bugs.launchpad.net/bugs/1807073 +https://bugs.launchpad.net/bugs/1813045 + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +Moreover, a lot of Proxmox users are complaining about the issue as well: +https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/ +https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/ \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/194 b/results/classifier/accel-gemma3:12b/vmm/194 new file mode 100644 index 000000000..b6d4a48d9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/194 @@ -0,0 +1,2 @@ + +Qemu fails to start with error " There is no option group 'spice'" diff --git a/results/classifier/accel-gemma3:12b/vmm/1940 b/results/classifier/accel-gemma3:12b/vmm/1940 new file mode 100644 index 000000000..84c91f546 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1940 @@ -0,0 +1,21 @@ + +Saving vm with shared folder results in Error: State blocked by non-migratable device '000.../vhost-user-fs' +Description of problem: +Saving a vm with savevm in the QEMU Monitor with a shared folder causes the following error message: +`Error: State blocked by non-migratable device '0000:00:05.0/vhost-user-fs'` +Steps to reproduce: +1. Get an qcow2 image that can boot (not sure if working qcow2 image is actually needed) +2. Start virtiofsd with this /usr/libexec/virtiofsd --socket-path=/tmp/virtiofs_socket -o source=/path/to/share +3. Run qemu-system-x86_64 -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem -smp 2 -hda image.qcow2 -vga qxl -virtfs local,path=/path/to/share,mount_tag=share,security_model=passthrough,id=virtiofs -chardev socket,id=char0,path=/tmp/virtiofs_socket -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=share +4. Let the image boot and/or go into the QEMU monitor. +5. type savevm testvm +6. See error. +Additional information: +This happens with both the legacy virtio-fs and the rust version. + +According to the first reply to https://gitlab.com/virtio-fs/virtiofsd/-/issues/81 there needs to be "a lot of changes not only in virtiofsd but also in the rust-vmm crates and qemu (and maybe in the vhost-user protocol)" so I'm reporting this here in the hopes it will speed something up. + +I followed the following to get virtiofsd working with command line QEMU: +https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system + +This is blocking our migration from VirtualBox because it doesn't have problems like this. The least I need is a work around or alternative shared filesystem. We are trying to avoid networked shares. diff --git a/results/classifier/accel-gemma3:12b/vmm/1946 b/results/classifier/accel-gemma3:12b/vmm/1946 new file mode 100644 index 000000000..367e5e97f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1946 @@ -0,0 +1,29 @@ + +High CPU Load after QEMU 8.1.1 +Description of problem: +Since the update there is a massive CPU load and this affects the CPU load of the router. +The VMs are partially for about 3min sporadically not accessible. +The VMs themselves were not adjusted and I have in the console. + +Using the VMM, I was able to see the message recorded below. + +`watchdog:_ BUG: soft lockup - CPU#0 stuck for 21s! [swapper/0:0]` + +I will also add some data like a XML file of a VM. +Additional information: + +[webproxy.log](/uploads/1d428f4c59b2397b9343a62dd8c4bce2/webproxy.log) + +[webproxy.xml](/uploads/04221c88956c49d76b4896dd8f6fd1f0/webproxy.xml) +[Host_Kernel.log](/uploads/f145bf599bf2003b89c17daaabb07143/Host_Kernel.log) + +Unfortunately I can't revert to the old QEMU version in the router OS but in the current state all my VM are not really 100% usable anymore. + +I would be very grateful if you could take a look at my case. + +many thanks in advance. + + + + +Paul diff --git a/results/classifier/accel-gemma3:12b/vmm/1949 b/results/classifier/accel-gemma3:12b/vmm/1949 new file mode 100644 index 000000000..58d5947a7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1949 @@ -0,0 +1,13 @@ + +chardev zombie TCP session +Description of problem: +When user terminates TCP session ungracefully (eg: power-cycle or network cable disconnect), the TCP session keeps in established status forever. In this state, new sessions can't access the chardev, since the zombie TCP session keeps exclusive access to chardev. +Steps to reproduce: +1.Establish client session to chardev TCP socket. +2.Power-off the client machine. +3.Establish a new client session +4.Observe that old TCP session is never killed and new session can connect but not interact with chardev. +Additional information: +Suggestions to resolve this and improve the chardev feature: +- enable TCP keep-alive for chardev server. +- allow multiple client sessions concurrently, where chardev output is broadcasted to all client sessions, and chardev input is shared by all clients. diff --git a/results/classifier/accel-gemma3:12b/vmm/1959 b/results/classifier/accel-gemma3:12b/vmm/1959 new file mode 100644 index 000000000..2074fb6df --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1959 @@ -0,0 +1,2 @@ + +qemu-img: support ZSTD compression level customization diff --git a/results/classifier/accel-gemma3:12b/vmm/196 b/results/classifier/accel-gemma3:12b/vmm/196 new file mode 100644 index 000000000..60968a455 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/196 @@ -0,0 +1,2 @@ + +Improve UX for macOS when launching from a fullscreen app diff --git a/results/classifier/accel-gemma3:12b/vmm/1966 b/results/classifier/accel-gemma3:12b/vmm/1966 new file mode 100644 index 000000000..7eabf0869 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1966 @@ -0,0 +1,9 @@ + +windows xp - some VM's hangs some working (regression?) +Description of problem: +Some of my XP instances behaves strange - seems that explorer.exe is unresponsive for about half an hour after start then works +- normally. +what is worse - there are instance which behaves normally - ie. after launch everything works as expected. +Steps to reproduce: +I want to know. +Additional information: +under qemu 8.0.4 all vms works. diff --git a/results/classifier/accel-gemma3:12b/vmm/1973 b/results/classifier/accel-gemma3:12b/vmm/1973 new file mode 100644 index 000000000..be15218e5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1973 @@ -0,0 +1,2 @@ + +Issues with dmabuf use in dbus interface diff --git a/results/classifier/accel-gemma3:12b/vmm/1980 b/results/classifier/accel-gemma3:12b/vmm/1980 new file mode 100644 index 000000000..343d0134d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1980 @@ -0,0 +1,14 @@ + +pipewire backend, bad mic sound +Description of problem: +Qemu VM and openSUSE share the webcam mic. +Pipewire is used by openSUSE. + +If using qemu with pa backend, there is no sound problem when mic is used by Skype in openSUSE. +If using qemu with pipewire backend and Skype used the mic then my contact says he does not recognize my voice and there are cracks. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/1982 b/results/classifier/accel-gemma3:12b/vmm/1982 new file mode 100644 index 000000000..fae16127c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1982 @@ -0,0 +1,10 @@ + +PS/2 mouse and keyboard not disabled when adding USB devices +Description of problem: +Documentation (such as https://www.qemu.org/docs/master/system/qemu-manpage.html or https://www.qemu.org/docs/master/system/devices/usb.html) says that enabling a USB keyboard or mouse (or tablet) will disable the PS/2 equivalent, but it seems both are present instead. +Steps to reproduce: +1. Pass a `-usbdevice` or `-device` option to QEMU. +2. Boot Haiku. +3. Find two identical devices in Preferences > Input, both `Extended PS/2 Mouse 1` and `USB Tablet 1`, as well as `AT Keyboard 1` and `USB Keyboard 1`. +Additional information: +The content of /var/log/syslog, which shows discovery of PS/2 devices: [syslog.zst](/uploads/7ed067538c94edfdbaf35ec92a422c68/syslog.zst) diff --git a/results/classifier/accel-gemma3:12b/vmm/1987 b/results/classifier/accel-gemma3:12b/vmm/1987 new file mode 100644 index 000000000..c64d4139d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1987 @@ -0,0 +1,49 @@ + +snapshot: main thread hangs for a while after 'loadvm' +Description of problem: +When I was testing qemu snapshots, I found that after the `loadvm` command, the virtual machine would often get stuck for a while, and it can **resume execution after I enter some characters into the terminal**, this is weird because my guest system doesn't need to accept input. + +After some debugging, I found that the guest kernel is executing a `wait` instruction in `__r4k_wait()`. + +And I found that the main thread usually does not sleep at `qemu_poll_ns()` during normal execution, but after `loadvm`, the timeout is set to a large value (related to the interval time of snapshot operations), causes the main thread to get stuck on 'qemu_poll_ns()'. + +After some analysis, I think it is because save/load_snapshot() does not handle timers related to QEMU_CLOCK_VIRTUAL well, such as `mips_timer_cb()`, resulting in incorrect value when calculating timeout. +Steps to reproduce: +1. Start emulation and connect monitor +2. `savevm` and wait for a moment +3. `loadvm` +Additional information: +Stack backtrace of the guest kernel: +``` +► 0 0x80104d40 __r4k_wait+32 + 1 0x80143cc4 cpu_startup_entry+284 + 2 0x80143cc4 cpu_startup_entry+284 + 3 0x80143cc4 cpu_startup_entry+284 + 4 0x80633fe0 kernel_init + 5 0x80825cb8 start_kernel+1072 +``` + +Stack backtrace of the main thread: +``` +0 0x7ffff74f0a96 ppoll+166 +1 0x555555ea4786 qemu_poll_ns+221 +2 0x555555e9fea7 os_host_main_loop_wait+93 +3 0x555555e9ffd6 main_loop_wait+187 +4 0x555555a644fd qemu_main_loop+46 +5 0x5555557d2b6a qemu_default_main+17 +6 0x5555557d2ba9 main+45 +7 0x7ffff7402083 __libc_start_main+243 +``` + +Stack backtrace of the vCPU thread: +``` +#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556550848) at ../sysdeps/nptl/futex-internal.h:183 +#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555564d0860 <qemu_global_mutex>, cond=0x555556550820) at pthread_cond_wait.c:508 +#2 __pthread_cond_wait (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>) at pthread_cond_wait.c:647 +#3 0x0000555555e85602 in qemu_cond_wait_impl (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>, file=0x5555560122ab "../system/cpus.c", line=431) at ../util/qemu-thread-posix.c:225 +#4 0x0000555555a5618f in qemu_wait_io_event (cpu=0x555556825200) at ../system/cpus.c:431 +#5 0x0000555555c8bcf1 in mttcg_cpu_thread_fn (arg=0x555556825200) at ../accel/tcg/tcg-accel-ops-mttcg.c:118 +#6 0x0000555555e85e50 in qemu_thread_start (args=0x555556550860) at ../util/qemu-thread-posix.c:541 +#7 0x00007ffff75d8609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#8 0x00007ffff74fd133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/1988 b/results/classifier/accel-gemma3:12b/vmm/1988 new file mode 100644 index 000000000..186ccfcbc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1988 @@ -0,0 +1,27 @@ + +8.2.0rc0 Regression: '-display vnc' opens gtk display as well +Description of problem: +A VNC display is requested, but a GTK frontend is opened as well. A VNC client is able to connect. +Steps to reproduce: +1. /configure --enable-fdt=internal --target-list=x86_64-softmmu +2. make +3. build/qemu-system-x86_64 -display vnc=:05 -k de +Additional information: +git bisect finally shows +``` +484629fc8141eaa257f961b5e5e310a1bbd0f1a2 is the first bad commit +commit 484629fc8141eaa257f961b5e5e310a1bbd0f1a2 +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Wed Oct 25 17:21:17 2023 +0400 + + vl: simplify display_remote logic + + Bump the display_remote variable when the -vnc option is parsed, just + like -spice. + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Thomas Huth <thuth@redhat.com> + + system/vl.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/199 b/results/classifier/accel-gemma3:12b/vmm/199 new file mode 100644 index 000000000..bc0696c43 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/199 @@ -0,0 +1,2 @@ + +Convert QAPI to static types diff --git a/results/classifier/accel-gemma3:12b/vmm/1997 b/results/classifier/accel-gemma3:12b/vmm/1997 new file mode 100644 index 000000000..7714543c5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/1997 @@ -0,0 +1,21 @@ + +Disk corruption on ARM64 (Apple Silicon) Linux VMs +Description of problem: +aarch64 Linux VMs will encounter disk corruption if they're set up with a filesystem that will notice it when it happens, e.g. BTRFS. This seems to be across the board with products, including Apple Hypervisor Framework, or just QEMU, so it very well might be an aarch64 Linux bug. +Steps to reproduce: +1. Install an aarch64 Linux VM using BTRFS as the root filesystem. ZFS might recognize silent corruption readily as well. +2. Run `stress-ng --iomix 4` +3. Check your `dmesg` and/or `btrfs check --force <device>` to check for filesystem corruption. +Additional information: +This is discussed in two other tickets, but I'm hoping to get more attention to the problem here. +[https://github.com/lima-vm/lima/issues/1957](https://github.com/lima-vm/lima/issues/1957) +[](https://github.com/utmapp/UTM/issues/4840) + + + + + +I can't seem to figure out how to upload images, but you can probably get to the image that I'm trying to share somehow... + + +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2002 b/results/classifier/accel-gemma3:12b/vmm/2002 new file mode 100644 index 000000000..9d5247570 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2002 @@ -0,0 +1,4 @@ + +Need to be able to set WM_CLASS under X11 +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2008 b/results/classifier/accel-gemma3:12b/vmm/2008 new file mode 100644 index 000000000..fa367dd47 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2008 @@ -0,0 +1,13 @@ + +querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry +Description of problem: +Querying the UUID in Powershell with +`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID` +will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present. + +Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part. + +It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS. +Additional information: +Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths): +https://forum.proxmox.com/threads/136942/ diff --git a/results/classifier/accel-gemma3:12b/vmm/2014 b/results/classifier/accel-gemma3:12b/vmm/2014 new file mode 100644 index 000000000..2485e1358 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2014 @@ -0,0 +1,54 @@ + +virtio: bounce.in_use==true in virtqueue_map_desc() +Description of problem: + +Steps to reproduce: +1. Build EDK II (edk2-stable202311) for riscv64 +2. Build UEFI SCT (commit 81dfa8d53d4290) for riscv64 +3. Run the UEFI SCT +4. Observe the message "qemu: virtio: bogus descriptor or out of resources" after which the execution stalls. + +The full procedure is described in https://github.com/xypron/sct_release_test + +To save time you can call `sct -u` and select only test 'MediaAccessTest\\BlockIOProtocolTest'. Run it with `F9`. +Additional information: +virtqueue_map_desc() may be called for a large buffers size `sz`. It will then call dma_memory_map() multiple times in a loop. In address_space_map() `bounce.in_use` is set to `true` on the first call. Each subsequent call is bound to fail. + +To verify this is the cause I applied the following diff: + +```plaintext +diff --git a/system/physmem.c b/system/physmem.c +index a63853a7bc..12b3c2f828 100644 +--- a/system/physmem.c ++++ b/system/physmem.c +@@ -3151,12 +3151,16 @@ void *address_space_map(AddressSpace *as, + + if (!memory_access_is_direct(mr, is_write)) { + if (qatomic_xchg(&bounce.in_use, true)) { ++ fprintf(stderr, "bounce.in_use in address_space_map\n"); ++ + *plen = 0; + return NULL; + } + /* Avoid unbounded allocations */ + l = MIN(l, TARGET_PAGE_SIZE); + bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, l); ++ if (!bounce.buffer) ++ fprintf(stderr, "Out of memory in address_space_map\n"); + bounce.addr = addr; + bounce.len = l; +``` + +and saw this output: + +```plaintext +Logfile: "\sct\Log\MediaAccessTest\BlockIOProtocolTest0\ReadBlocks_Conf_0_0_8261 +59D3-04A5-4CCE-8431-344707A8B57A.log" +Test Started: 12/02/23 08:43a +------------------------------------------------------------ +Current Device: Acpi(PNP0A03,0)/Pci(3|0) +Bounce.in_use in address_space_map +qemu: virtio: bogus descriptor or out of resources +``` + +See related bug #850. diff --git a/results/classifier/accel-gemma3:12b/vmm/2019 b/results/classifier/accel-gemma3:12b/vmm/2019 new file mode 100644 index 000000000..dc00fcfe0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2019 @@ -0,0 +1,27 @@ + +Additional network device is not recognized on windows guest vm +Description of problem: +I have a problem for using Windows 2019/2022 guest vm as QEMU. +When I add a network device more online, it isn't work and recognized. +There is an error occurs at the Device Manager. + + + +I added network device with this qmp command +``` +'{ "execute": "chardev-add", "arguments":{"id":"charnet_35", "backend": { "type" : "socket", "data" : { "addr" : { "type" : "unix", "data" : {"path" : "/tmp/17115.1''"}}, "server" : true, "wait" : false }}}}' | nc -U $socket -N +'{ "execute": "netdev_add", "arguments":{"type":"vhost-user", "id":"'hostnet_35", "chardev":"charnet_35", "queues":2 }}' | nc -U $socket -N +'{ "execute" : "device_add", "arguments" : {"driver" : "virtio-net-pci", "mq":"on" ,"vectors":6, "netdev":"hostnet_35", "id":"dpdk_35", "mac":"F2:20:AF:40:12:65", "bus" : "bridge", "addr" : "0x8", "page-per-vq": "on", "rx_queue_size" : 1024, "tx_queue_size": 1024, "mrg_rxbuf" : "on", "disable-legacy": "on", "disable-modern" : "off" , "host_mtu" : 1500, "csum" : "on", "guest_csum" : "on", "host_tso4" : "on", "host_tso6" : "on"}}' | nc -U $socket -N +``` + +But, I can check recognized additional Network device after Windows guest vm rebooted. +Steps to reproduce: +1. Boot Windows 2019/2022 guest vm +2. Add chardev, netdev, device more with qmp command as hotplug +3. Check Network device recognition on the guest os +Additional information: +- I'm using hardware vDPA offloading with mellanox NIC card. +And When I use tap device instead vhost-user at the netdev, I don't have any problem. That error does not occured + +- And second, when I disable the first NIC, The additional NIC is recognized. + diff --git a/results/classifier/accel-gemma3:12b/vmm/202 b/results/classifier/accel-gemma3:12b/vmm/202 new file mode 100644 index 000000000..c0a3619e4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/202 @@ -0,0 +1,2 @@ + +Move scripts/qmp/qom-* tooling into qemu.qmp.* diff --git a/results/classifier/accel-gemma3:12b/vmm/2024 b/results/classifier/accel-gemma3:12b/vmm/2024 new file mode 100644 index 000000000..86bcbe6ff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2024 @@ -0,0 +1,31 @@ + +IPv6 DHCPv6 DUID-UUID Generation Issue with iPXE on QEMU 8.1.2 and SMBIOS 3.0 +Description of problem: +I'm creating this ticket in both projects affected as I'm unsure which side needs to resolve it. I discovered this bug after upgrading Proxmox to version 8.1. I use iPXE to boot in IPv6 and retrieve the configuration from a web server. I have a DHCPv6 and SLAAC server configured. + +In this configuration, iPXE is unable to generate the necessary DUID-UUID for IPv6. If I revert to the previous QEMU version (using the machine: pc-i440fx-8.0 option in Proxmox), I have no issues. The only difference I notice and understand is the switch to SMBIOS 3.0, which is 64 bits, compared to SMBIOS 2.8, which is 32 bits. It appears to be the same issue with Libvirt. By default, it uses pc-q35-8.1, and I encounter the bug. However, if I switch to pc-q35-8.0, the problem is resolved. + +I've included two sets of information in the first part. The first one is from my local computer using libvirt, making it easier to reproduce the bug. The second set is from my production environment. + +Here's the iPXE trace: + +```plaintext +iPXE> ifconf --configurator ipv6 +Configuring [ipv6] (net0 66:b5:3e:97:7d:4e)... +DHCPv6 net0 could not create DUID-UUID: No such file or directory (https://ipxe.org/2d0c203b) +No such file or directory (https://ipxe.org/2d0c203b) +``` +Steps to reproduce: +1. Create a PXE ISO with IPv6 debug options: + 1. Clone the iPXE repository with the following command: + * `git clone https://github.com/ipxe/ipxe` + 2. Navigate to the src directory: + * `cd ipxe/src` + 3. Build the iPXE ISO with IPv6 debug options using the following command: + * `DEBUG='dhcpv6,neighbour' make bin/ipxe.iso` +2. Set up a Libvirt network with DHCPv6 enabled (example configuration provided in the next section). +3. Create a virtual machine with the generated iPXE ISO and the network configured for IPv6. +4. Press `Ctrl+B` to access the iPXE shell. +5. Execute the command `ifconf --configurator ipv6` in the iPXE shell. +Additional information: +# diff --git a/results/classifier/accel-gemma3:12b/vmm/203 b/results/classifier/accel-gemma3:12b/vmm/203 new file mode 100644 index 000000000..0bfc13d07 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/203 @@ -0,0 +1,2 @@ + +move ./scripts/qapi/ to ./python/qemu/qapi/ diff --git a/results/classifier/accel-gemma3:12b/vmm/2031 b/results/classifier/accel-gemma3:12b/vmm/2031 new file mode 100644 index 000000000..42cb4285d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2031 @@ -0,0 +1,14 @@ + +Redundant comparison +Description of problem: +The result of the function `qdev_get_hotplug_handler` is always __NULL__. That is why the comparison in the line №502 is redundant: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/qdev.c#L501 + +This code will never be executed: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/qdev.c#L502-L507 + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Voronin. diff --git a/results/classifier/accel-gemma3:12b/vmm/2039 b/results/classifier/accel-gemma3:12b/vmm/2039 new file mode 100644 index 000000000..11ef68e27 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2039 @@ -0,0 +1,12 @@ + +there is no 'write' lock checked when exec `qemu-img check lvqcow2` +Description of problem: +There is a difference between a qcow2 file image and a lvqcow2 img. + +'write' lock will be checked when using a normal qcow2-format image (/path/to/img/test.qcow2) to avoid some risky operations. However, when I create a qcow2 img on a lv, there is not any write lock checked when I perform `qemu-img check` on this lvqcow2 even though it was attached to a vm. +Steps to reproduce: +1. create a lvqcow2: `qemu-img create -f qcow2 /path/to/lv xxG` +2. create a vm using this lvqcow2 +3. exec `qemu-img check` on this lvqcow2, there is no any perm (such as 'write' lock) check and notifaction even though this lvqcow2 is using in qemu vm. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2042 b/results/classifier/accel-gemma3:12b/vmm/2042 new file mode 100644 index 000000000..85e5f9504 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2042 @@ -0,0 +1,19 @@ + +Not able to reboot Linux guest on Windows host +Description of problem: +I am running Linux Mint on Windows, but when I try to reboot the machine, I get the following error: + +qemu: WHPX: Unexpected VP exit code 4 + +I did some experiments changing the flags I use when I launch Qemu and I realized that if I set -smp 1 it does not fail. Furthermore, if I set the irqchip to off (kernel-irqchip=off) it does not fail either, but both options do not have good performance at all. I realized too that if I set 4 cores (-smp 4), the error might appear up to 4 times. + +What seems to be failing then is the APIC emulation that Hyper-V provides. Does anyone know if: + +1. Am I missing a flag when launching Qemu? +2. Is it there a patch to solve this? + +Any leads for solving this problem would be highly appreciated. +Steps to reproduce: +1. Install MSYS +2. Open MSYS and run pacman -S mingw-w64-x86_64-qemu +3. Launch Qemu and reboot machine diff --git a/results/classifier/accel-gemma3:12b/vmm/2050 b/results/classifier/accel-gemma3:12b/vmm/2050 new file mode 100644 index 000000000..4553916fe --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2050 @@ -0,0 +1,8 @@ + +Graphical glitch on boot screen of ubuntu aarch64 +Description of problem: +Glitches on boot screen. +Additional information: + + +(The "TIANO Core" screen before this has similar issues) diff --git a/results/classifier/accel-gemma3:12b/vmm/2052 b/results/classifier/accel-gemma3:12b/vmm/2052 new file mode 100644 index 000000000..8db3ec8d0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2052 @@ -0,0 +1,2 @@ + +sdl window partially catches mouse cursor diff --git a/results/classifier/accel-gemma3:12b/vmm/2056 b/results/classifier/accel-gemma3:12b/vmm/2056 new file mode 100644 index 000000000..b046d17fa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2056 @@ -0,0 +1,15 @@ + +macOS Cocoa title bar covers top of VM screen +Description of problem: +When using the Cocoa interface the title bar covers the top part of the VM screen. In Windows XP, using show-cursor=on and USB tablet (-usb -device usb-tablet,bus=usb-bus.0), the mouse cursor seems to be off by the height of the title bar; to click on a target the mouse cursor has to be below the target by about the height of the top bar. +Steps to reproduce: +1. Run Qemu using the Cocoa-interface (-display cocoa) +Additional information: +The problem exists in both Qemu 8.2.0 (compiled from source) as well as in the MacPorts version (version 8.0.5). Further testing shows the same problem in versions 6.2.0, 7.0.0, and 7.1.0. This problem did not exist in previous versions of macOS. + +A screenshot is enclosed: + + +For similar reports, see: https://www.emaculation.com/forum/viewtopic.php?p=77350#p77350 and https://github.com/phil-opp/blog_os/issues/1249#issuecomment-1825933581 and https://68kmla.org/bb/index.php?threads/a-self-contained-qemu-based-a-ux-system-for-macos.45106/post-504970 + +The problem exists on both Apple Silicon and Intel hardware. diff --git a/results/classifier/accel-gemma3:12b/vmm/2063 b/results/classifier/accel-gemma3:12b/vmm/2063 new file mode 100644 index 000000000..08c96c89b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2063 @@ -0,0 +1,56 @@ + +Poor performance with -accel whpx on Server 2022 host, windows 10 guest - missing CPUID hypervisor ident data? +Description of problem: +**Performance of Windows 10 x64 QEMU virtual machine is essentially unusable, compared to same image running under Hyper-V on the same host system.** + +It appears the VM is not being provided the Hyper-V enlightenment hints while running under QEMU. The hv-XXX cpu options do not appear applicable to -accel WHPX. + +Below are dumps of the 0x40000000 cpuid values on the host, QEMU guest, and Hyper-V guest (exact same .VHD file used, nested virtualization not enabled for this VM). + +host: +- 0x40000000 eax=4000000c ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=bfff ebx=2bb9ff ecx=22 edx=71fffbf6 +- 0x40000004 eax=50d1c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=400 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=1e00be ebx=0 ecx=0 edx=0 +- 0x40000007 eax=80000007 ebx=3 ecx=0 edx=0 +- 0x40000008 eax=100001 ebx=1 ecx=aaaa edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 + +qemu guest with -accel whpx : +- 0x40000000 eax=40000010 ebx=0 ecx=0 edx=0 +- 0x40000001 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000003 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000004 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000005 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000006 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000d eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000e eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000f eax=0 ebx=0 ecx=0 edx=0 +- 0x40000010 eax=225519 ebx=30d40 ecx=0 edx=0 + +hyperv guest VM: (nested virtualization not enabled) +- 0x40000000 eax=4000000b ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=ae7f ebx=388030 ecx=22 edx=e0bed7b2 +- 0x40000004 eax=40c2c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=f0 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=e ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 diff --git a/results/classifier/accel-gemma3:12b/vmm/2070 b/results/classifier/accel-gemma3:12b/vmm/2070 new file mode 100644 index 000000000..d3df3c126 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2070 @@ -0,0 +1,10 @@ + +TCG acceleration + EDK2 + Secure Boot hangs on boot since qemu 8.2 +Description of problem: +Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware. +Steps to reproduce: +1. `git clone https://github.com/systemd/mkosi` +2. `cd mkosi` +3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2073 b/results/classifier/accel-gemma3:12b/vmm/2073 new file mode 100644 index 000000000..f2053bb6c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2073 @@ -0,0 +1,17 @@ + +Audio: missing ability to disable microphone input from host? +Description of problem: +**It appears there is no way to disable the microphone / input to the audio backend device(s).** + + +There are at least two cases where this matters: +1. The host has no microphone input (e.g. only HDMI audio output with video). +2. The host has a microphone input, but the user doesn't want the guest VM to have access to the microphone/input. + +I tried the option in.channels=0, as that seemed the most obvious way, though that doesn't work. + +For -audio dsound, it appears that CLSID_DirectSoundCapture is unconditionally acquired. + +There will also be later periodic warning/text outputs from QEMU "Could not create a backend for voice virtio.in", if you're running on a host system with no audio input device. + +Adding a couple backend checks for channels > 0 may work well. Not sure if it matters that audio front end device in the VM still thinks there is an audio input. diff --git a/results/classifier/accel-gemma3:12b/vmm/2075 b/results/classifier/accel-gemma3:12b/vmm/2075 new file mode 100644 index 000000000..8ba561f4e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2075 @@ -0,0 +1,11 @@ + +QGA guest-get-fsinfo can not return windows dynamic volumes +Description of problem: +Install qemu-ga (newest version) in Windows, create multiple dynamic volumes（containing multiple disks）, + + +get them information via guest-get-fsinfo, but guest-get-fsinfo does not return the the dynamic volume. +Steps to reproduce: +virsh qemu-agent-command {domain} --pretty '{ "execute": "guest-get-fsinfo" }' +Additional information: +Please see if this bug can be fixed by [qga-win: Fix guest-get-fsinfo multi-disks collection](https://patchew.org/QEMU/20231227071540.4035803-1-peng.ji@smartx.com/) diff --git a/results/classifier/accel-gemma3:12b/vmm/2085 b/results/classifier/accel-gemma3:12b/vmm/2085 new file mode 100644 index 000000000..b8e543e3c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2085 @@ -0,0 +1,23 @@ + +screen doesn't update fully wth spice + virtio-vga graphics +Description of problem: +When using spice graphics with virtio-vga, display updates and missing and/or delayed making interaction unusable +Steps to reproduce: +Create a VM with spice graphics and virtio-vga with earlier mentioned command line + +Open ``remote-viewer spice://localhost:5900`` + +Boot the Fedora 39 server network installer CDROM ISO + +When Ananconda starts, select 'continue' at the first language choice screen + +Select 'Root Account' config option + +Toggle between "Disable root account" and "Enable root account" options + +Observe when the password entry box is shown/hidden, the screen does not redraw correctly +Additional information: +See also + +https://bugzilla.redhat.com/show_bug.cgi?id=2256884 +https://bbs.archlinux.org/viewtopic.php?id=291606 diff --git a/results/classifier/accel-gemma3:12b/vmm/2086 b/results/classifier/accel-gemma3:12b/vmm/2086 new file mode 100644 index 000000000..a266a3551 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2086 @@ -0,0 +1,16 @@ + +qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" on ESXi +Description of problem: +Trying to start the VM using vmdk converted with qemu-img fails with + +Failed to start the virtual machine. +Module DevicePowerOn power on failed. +Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' +Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported. +Steps to reproduce: +1. Convert booting OS (in both Qemu and VMWare with the help of drivers) to vmdk +2. Push vmdk file to ESXi datastore +3. Try to boot + +Additional information: +ESXi seem to use a specific implementation of vmdk, with a *name*.vmdk file being the descriptor of the virtual disk and a *name*-flat.vmdk. diff --git a/results/classifier/accel-gemma3:12b/vmm/2087 b/results/classifier/accel-gemma3:12b/vmm/2087 new file mode 100644 index 000000000..d554e6415 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2087 @@ -0,0 +1,29 @@ + +usb-host / libusb: handling of clear_halt leads to slow device attach, possibly unusable VMs (edit:fix within) +Description of problem: +When passing through a common JMicron USB SATA IDE brige storage device to a windows guest, the windows VM and the attached device become unusable. It appears to take several minutes to identify the connected device, and many minutes to pull up the device properties (though they are correct). The trace log seems to indicate a retry/reset retry loop is occuring. + +The device works fine passed through to a fedora guest VM. Device also work fine when used by the Windows host system. + +The primary difference may be the XHCI controller device behavior in the Windows and fedora guest VMs.\ +It appears there may possibly be 2 separate issues: + +1. Incompatible handling of this type of storage device in usb-host / libusb. +2. Windows XHCI not properly handling malformed or possibly mis-behaved devices. + +I also tried the nec-usb-xhci device instead of qemu-xhci, and also tried the ICH9 usb device; no difference in behavior in the Windows VM. (Though windows appears to use the same xhci device driver in all cases). + +A simple USB 3.x storage stick (at speed 5000) works fine passed through to the Windows guest VM, configured in the same way, with both cases using WinUSB to allow passthrough/attach to work. +Additional information: +lsusb output in the working Fedora VM case: + +only the debug descriptor fails to dump, running as root + +[lsusb.txt](/uploads/c1a702bc628ed9bc983dba3e703e8af4/lsusb.txt) + +\-trace enable=usb_host\_\* output (fragment of logfile) from the non-working Windows VM case: + +[usb_noprogress.txt](/uploads/f66b2ff7d4658f9569859ac122413d9f/usb_noprogress.txt) + +```plaintext +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2090 b/results/classifier/accel-gemma3:12b/vmm/2090 new file mode 100644 index 000000000..65e212078 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2090 @@ -0,0 +1,8 @@ + +Long initialisation of VM before boot. +Description of problem: +When i start VM in "Virtual machine manager" I got black screen, which hang there approximately one minute. After this delay VM begin booted and all work properly. Some time ago VMs booted immediately without mentioned delay after starting of VM. I checked all relevant log files, changed 3 times kernel, rebuilded Qemu, but problem persist. I don't know when problem began. + + + +## diff --git a/results/classifier/accel-gemma3:12b/vmm/2095 b/results/classifier/accel-gemma3:12b/vmm/2095 new file mode 100644 index 000000000..8e02e2644 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2095 @@ -0,0 +1,2 @@ + +RFE: support AF_UNIX userspace backend for virtio-vsock matching firecracker diff --git a/results/classifier/accel-gemma3:12b/vmm/2099 b/results/classifier/accel-gemma3:12b/vmm/2099 new file mode 100644 index 000000000..6e427092f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2099 @@ -0,0 +1,12 @@ + +Setting for initial GTK window size? +Description of problem: + +Steps to reproduce: +1. When starting QEMU on Windows, the GTK window size appears to be sized to approx 640x480, which is very hard to see on a 4k+ monitor. So interacting with the boot, reading BIOS messages, etc, isn't great. +2. It would be great to be able to specify the dimensions of the GTK window, say 2560x1600, and then just set "Zoom to Fit". +3. This way, the visible window area remains constant, and all stages of graphical interaction get scaled to a workable size. +4. The OS can be configured to say 2560x1600 once setup. +5. Perhaps I've overlook settings to accomplish this? + +Thank you. diff --git a/results/classifier/accel-gemma3:12b/vmm/210 b/results/classifier/accel-gemma3:12b/vmm/210 new file mode 100644 index 000000000..c2bb0f1a3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/210 @@ -0,0 +1,2 @@ + +Function not implemented when using libaio diff --git a/results/classifier/accel-gemma3:12b/vmm/2100 b/results/classifier/accel-gemma3:12b/vmm/2100 new file mode 100644 index 000000000..8269f4755 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2100 @@ -0,0 +1,7 @@ + +Add option to skip quit confirmation with Cocoa display +Additional information: +This change was originally requested in back in 2016, but got lost in the issue tracker migration: https://bugs.launchpad.net/qemu/+bug/1556372 + +Patch in question: +https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html diff --git a/results/classifier/accel-gemma3:12b/vmm/2109 b/results/classifier/accel-gemma3:12b/vmm/2109 new file mode 100644 index 000000000..9812456be --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2109 @@ -0,0 +1,2 @@ + +NetBSD VM fails to install due to missing py311-expat package diff --git a/results/classifier/accel-gemma3:12b/vmm/2111 b/results/classifier/accel-gemma3:12b/vmm/2111 new file mode 100644 index 000000000..e805782ea --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2111 @@ -0,0 +1,60 @@ + +Assertion failure with active vhost NIC when snapshot_save_job_bh() is executed as part of a vCPU thread's aio_poll() +Description of problem: +During a `snapshot-save` QMP command the `snapshot_save_job_bh()` bottom half can end up being executed as part of a vCPU thread's `aio_poll()`. This is problematic and can lead to an assertion failure (see below for backtrace) when there is an active vhost network device: + +``` +qemu-system-x86_64: ../hw/net/virtio-net.c:3835: virtio_net_pre_save: Assertion `!n->vhost_started' failed. +``` +Steps to reproduce: +It is very racy and very difficult to reproduce when actually taking snapshots. So the way I can get it pretty reliably is: + +1. Issue `snapshot-save` QMP commands with an invalid device ID in a loop. At the same time, have the guest write to the pflash. +2. In GDB, wait for `snapshot_save_job_bh()` to be hit by a vCPU thread. +3. Manually change the device ID to a valid one (`scsi1` in the example) so that taking a snapshot will actually be attempted. +4. Continue in GDB and the assertion failure will happen. +Additional information: +Full backtrace: + +``` + #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 + #1 0x00007f1de5ae3d9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 + #2 0x00007f1de5a94f32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 + #3 0x00007f1de5a7f472 in __GI_abort () at ./stdlib/abort.c:79 + #4 0x00007f1de5a7f395 in __assert_fail_base (fmt=0x7f1de5bf3a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", + file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:92 + #5 0x00007f1de5a8de32 in __GI___assert_fail (assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, + function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:101 + #6 0x0000563cb8ebf23c in virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3835 + #7 virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3829 + #8 0x0000563cb917515b in vmstate_save_state_v (f=0x7f1dc43aec30, vmsd=0x563cb9e5a580 <vmstate_virtio_net>, opaque=0x563cbbb6eb40, vmdesc=0x7f1dc4080040, version_id=11, errp=0x7f1dcbdf9908) + at ../migration/vmstate.c:359 + #9 0x0000563cb9175d0c in vmstate_save_state_with_err (f=<optimized out>, vmsd=<optimized out>, opaque=<optimized out>, vmdesc_id=<optimized out>, errp=<optimized out>) at ../migration/vmstate.c:347 + #10 0x0000563cb8d9a1b2 in vmstate_save (f=f@entry=0x7f1dc43aec30, se=se@entry=0x563cbbcbdc70, vmdesc=vmdesc@entry=0x7f1dc4080040) at ../migration/savevm.c:1037 + #11 0x0000563cb8d9d6e6 in qemu_savevm_state_complete_precopy_non_iterable (f=f@entry=0x7f1dc43aec30, in_postcopy=in_postcopy@entry=false, inactivate_disks=inactivate_disks@entry=false) + at ../migration/savevm.c:1553 + #12 0x0000563cb8d9daa2 in qemu_savevm_state_complete_precopy (f=f@entry=0x7f1dc43aec30, iterable_only=iterable_only@entry=false, inactivate_disks=inactivate_disks@entry=false) at ../migration/savevm.c:1628 + #13 0x0000563cb8da076e in qemu_savevm_state (errp=0x7f1dc42c59f0, f=0x7f1dc43aec30) at ../migration/savevm.c:1734 + #14 save_snapshot (name=<optimized out>, overwrite=overwrite@entry=false, vmstate=<optimized out>, has_devices=has_devices@entry=true, devices=0x7f1dc4096600, errp=0x7f1dc42c59f0) at ../migration/savevm.c:3131 + #15 0x0000563cb8da0926 in snapshot_save_job_bh (opaque=0x7f1dc42c5930) at ../migration/savevm.c:3430 + #16 0x0000563cb9110036 in aio_bh_poll (ctx=ctx@entry=0x563cba818b40) at ../util/async.c:216 + #17 0x0000563cb90fa09a in aio_poll (ctx=ctx@entry=0x563cba818b40, blocking=blocking@entry=true) at ../util/aio-posix.c:722 + #18 0x0000563cb8fb1015 in bdrv_poll_co (s=0x7f1dcbdf9db0) at /home/febner/repos/qemu/block/block-gen.h:43 + #19 blk_pwrite (blk=<optimized out>, offset=offset@entry=91136, bytes=bytes@entry=512, buf=0x7f1dc9a16400, flags=flags@entry=0) at block/block-gen.c:2012 + #20 0x0000563cb8bb8985 in pflash_update (pfl=pfl@entry=0x563cbaa84bf0, offset=91136, offset@entry=91526, size=size@entry=1) at ../hw/block/pflash_cfi01.c:394 + #21 0x0000563cb8bbacd8 in pflash_write (be=0, width=1, value=63, offset=91526, pfl=0x563cbaa84bf0) at ../hw/block/pflash_cfi01.c:522 + #22 pflash_mem_write_with_attrs (opaque=0x563cbaa84bf0, addr=91526, value=<optimized out>, len=1, attrs=...) at ../hw/block/pflash_cfi01.c:681 + #23 0x0000563cb8f06e2e in access_with_adjusted_size (addr=addr@entry=91526, value=value@entry=0x7f1dcbdf9f58, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, + access_fn=0x563cb8f06710 <memory_region_write_with_attrs_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 + #24 0x0000563cb8f07e59 in memory_region_dispatch_write (mr=mr@entry=0x563cbaa84fb0, addr=addr@entry=91526, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528 + #25 0x0000563cb8f0f43c in flatview_write_continue (fv=fv@entry=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f1de7946028, len=len@entry=1, addr1=<optimized out>, + l=<optimized out>, mr=0x563cbaa84fb0) at ../system/physmem.c:2714 + #26 0x0000563cb8f0f6b3 in flatview_write (fv=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=len@entry=1) at ../system/physmem.c:2756 + #27 0x0000563cb8f12959 in address_space_write (len=1, buf=0x7f1de7946028, attrs=..., addr=4290864518, as=0x563cb9fd8ec0 <address_space_memory>) at ../system/physmem.c:2863 + #28 address_space_rw (as=0x563cb9fd8ec0 <address_space_memory>, addr=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=1, is_write=<optimized out>) at ../system/physmem.c:2873 + #29 0x0000563cb8f64ab8 in kvm_cpu_exec (cpu=cpu@entry=0x563cbac066d0) at ../accel/kvm/kvm-all.c:2915 + #30 0x0000563cb8f65ce5 in kvm_vcpu_thread_fn (arg=arg@entry=0x563cbac066d0) at ../accel/kvm/kvm-accel-ops.c:51 + #31 0x0000563cb90fd1c8 in qemu_thread_start (args=0x563cbaac33c0) at ../util/qemu-thread-posix.c:541 + #32 0x00007f1de5ae2044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 + #33 0x00007f1de5b6261c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2115 b/results/classifier/accel-gemma3:12b/vmm/2115 new file mode 100644 index 000000000..385fc15b6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2115 @@ -0,0 +1,55 @@ + +HVF accelerator crash in vmx_write_mem (mmu_gva_to_gpa) +Description of problem: +During the installation of Windows 2000 from CD-ROM (image), following disk initialization/formatting, a base operating system is copied to the (virtual) hard disk and the system is rebooted. During the start from hard disk to resume installation, QEMU crashes. + +This crash occurs whether using installation media for Windows 2000 Professional or Windows 2000 Advanced Server. It can be reproduced before any product key or Terminal Services licensing information is entered. + +Undertaking the same process with TCG accelerator on the same host, the issue is not observed. + +Unlike in #1603, `-pdpe1gb` does not work around this crash. +Steps to reproduce: +1. In HVF QEMU accelerator on x86_64 macOS, start up a pc-i440fx virtual machine w/ Windows 2000 (SP4) installation media. +2. Initialize/format a (qcow2-powered) hard drive as NTFS when prompted. +3. Allow the system to reboot. +Additional information: +Crash stderr: +``` +vmx_write_mem: mmu_gva_to_gpa bfd391f0 failed +<pid> Abort trap: 6 +``` +(it's always "bfd391f0") + +Stacktrace: +``` +0 libsystem_kernel.dylib 0x7ff8164771e2 __pthread_kill + 10 +1 libsystem_pthread.dylib 0x7ff8164aeee6 pthread_kill + 263 +2 libsystem_c.dylib 0x7ff8163d5b45 abort + 123 +3 qemu-system-x86_64 0x106a3d98d vmx_write_mem + 190 +4 qemu-system-x86_64 0x106a39f1c write_val_ext + 88 +5 qemu-system-x86_64 0x106a3cb1c exec_movs_single + 92 +6 qemu-system-x86_64 0x106a3c412 exec_movs + 61 +7 qemu-system-x86_64 0x106a3b35e exec_instruction + 48 +8 qemu-system-x86_64 0x106a36707 hvf_vcpu_exec + 2411 +9 qemu-system-x86_64 0x106b16532 hvf_cpu_thread_fn + 283 +10 qemu-system-x86_64 0x106c752fc qemu_thread_start + 130 +11 libsystem_pthread.dylib 0x7ff8164af1d3 _pthread_start + 125 +12 libsystem_pthread.dylib 0x7ff8164aabd3 thread_start + 15 +``` + +Registers at crash: +``` +rax: 0x0000000000000000 rbx: 0x000070000322d000 rcx: 0x000070000322cc58 rdx: 0x0000000000000000 +rdi: 0x0000000000001103 rsi: 0x0000000000000006 rbp: 0x000070000322cc80 rsp: 0x000070000322cc58 + r8: 0x00007ff859b93d08 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000246 +r12: 0x0000000000001103 r13: 0x0000000000000000 r14: 0x0000000000000006 r15: 0x0000000000000016 +rip: 0x00007ff8164771e2 rfl: 0x0000000000000246 cr2: 0x0000000000000000 +``` + +OS response: +**Exception Type:** EXC_CRASH (SIGABRT) +**Exception Codes:** 0x0000000000000000, 0x0000000000000000 +**Termination Reason:** Namespace SIGNAL, Code 6 Abort trap: 6 +**Logical CPU:** 0 +**Error Code:** 0x02000148 +**Trap Number:** 133 diff --git a/results/classifier/accel-gemma3:12b/vmm/2116 b/results/classifier/accel-gemma3:12b/vmm/2116 new file mode 100644 index 000000000..d04cf8a8b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2116 @@ -0,0 +1,29 @@ + +[CRASH] OpenGL acceleration except gtk: bad interaction between NVIDIA usermode opengl libraries and QEMU seccomp -sandbox on,spawn=deny, crashes immediately on startup with Bad system call +Description of problem: +When running any of the above command lines, QEMU crashes with Bad system call (core dumped). Not exclusive to spice; it seems this is caused by QEMU forking during OpenGL initialization after seccomp takes effect. +Steps to reproduce: +1. Run the above commandline +2. Notice a Bad system call (core dumped) +Additional information: +This crash only happens if spawn=deny is set, resourcecontrol/obsolete/elevateprivileges don't cause crashes. + +The crash happens around the same time as an audit event is generated in dmesg: `audit: type=1326 audit(1705775880.776:14): auid=MYUSERID uid=MYUID gid=MYGID ses=REDACTED pid=REDACTED comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=REDACTED code=REDACTED` + +`ausyscall c000003e 56` tells me it's `clone` which (iirc) is the syscall used by glibc to implement fork() (I might be wrong about glibc part) + +Suggested solution: move seccomp activation until just before guest code starts executing? make frontends (ie -display gtk/sdl/whatever, including -spice) initialize before seccomp? + +Workaround: `chmod -x /bin/nvidia-modprobe` if not using the NVIDIA gpu or use this wrapper script (untested, not enterprise-ready, I am not responsible if unexpected things happen): +- rename /bin/qemu-system-x86_64 to qemu-system-x86_64.real +- put this in /bin/qemu-system-x86_64 and chmod +x it +```sh +#!/usr/bin/env sh +chmod -x /bin/nvidia-modprobe +qemu-system-x86_64.real $@ & disown +sleep 10 # excessive but maybe safer? +chmod +x /bin/nvidia-modprobe +``` +Also, you can use -display gtk,gl=on instead, or (unknown security implications) remove spawn=deny from -sandbox args + +original bug report was https://gitlab.com/libvirt/libvirt/-/issues/585 but I realized this was more of a qemu issue than a libvirt one diff --git a/results/classifier/accel-gemma3:12b/vmm/2117 b/results/classifier/accel-gemma3:12b/vmm/2117 new file mode 100644 index 000000000..0568f7132 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2117 @@ -0,0 +1,28 @@ + +Unraid, Ubuntu, 9P/virtio and memory issues +Description of problem: +I am running an Ubuntu VM on Unraid - which is using Qemu. I am exposing my shares through "9p Mode" to the VM. + +The logs shows: +-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/mnt/user/backup \ +-device '{"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"backup","bus":"pci.1","addr":"0x0"}' \ + +Inside Ubuntu, I mount the exposed shares like this: + +sudo mount -t 9p -o trans=virtio "backup" /media/share/backup + +I have a script that uses rsync to sync the files from these mounted shares onto an internal disk drive. + +The issues that I am facing, is that rsync sometimes reports "cannot allocate memory": + +rsync: [sender] readdir("/media/share/backup/myfolder"): Cannot allocate memory (12) + +There are "ten thousands" of files in that folder hierarchy, but there are plenty of memory available on the VM (many GBs), so that is no issue. The next time I run the job, it might go through as normal. But I would like to get rid of these issues. + +The question is: Is there some kind of memory allocation/limit to the virtio/9p as well? If yes - is there some way to increase it to avoid these errors? +Steps to reproduce: +1. Mount as shown +2. Run rsync on folder with lots of files +3. See error +Additional information: +N/A diff --git a/results/classifier/accel-gemma3:12b/vmm/214 b/results/classifier/accel-gemma3:12b/vmm/214 new file mode 100644 index 000000000..03d87dffa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/214 @@ -0,0 +1,2 @@ + +QEMU manpages provoke man(1) "can't break line" warnings diff --git a/results/classifier/accel-gemma3:12b/vmm/2148 b/results/classifier/accel-gemma3:12b/vmm/2148 new file mode 100644 index 000000000..35e008299 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2148 @@ -0,0 +1,10 @@ + +vdso.so is required to build vdso.so since 8.2.0 +Description of problem: +Removing binaries from the "source" distribution makes it unable to compile. It used to work in 8.1.4. +Steps to reproduce: +1. remove **/vdso.so +2. configure, build +3. `../linux-user/i386/meson.build:7:20: ERROR: File vdso.so does not exist.` +Additional information: +Build log in my Gentoo harness: [build.log](/uploads/da1933173b39dd6e5f9f90de09adc3a1/build.log) diff --git a/results/classifier/accel-gemma3:12b/vmm/2158 b/results/classifier/accel-gemma3:12b/vmm/2158 new file mode 100644 index 000000000..5fe6a98e4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2158 @@ -0,0 +1,10 @@ + +Qemu will not release mouse even after using the release mouse keybind +Description of problem: +There wasn't a crash but this is an annoying problem. The mouse does not release when the VM sizes the window larger because, as far as I know, qemu moves the window and relies on the user to click to release the mouse. +Steps to reproduce: +1. Open qemu +2. Try to release the mouse using the keybind shown. +3. It move the window and won't release. +Additional information: +In case it's really needed, I am using a custom QEMU VM Manager called "QEMU Manager". diff --git a/results/classifier/accel-gemma3:12b/vmm/2167 b/results/classifier/accel-gemma3:12b/vmm/2167 new file mode 100644 index 000000000..91b9e505a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2167 @@ -0,0 +1,41 @@ + +The GPIO controllers connected to the emulated PCIe bus via vhost-user can't generate interrupts. +Description of problem: +The problem is related to emulation of GPIO controllers using the vhost-user protocol for GPIO. The problem was detected when using the [vhost-device-gpio](https://github.com/rust-vmm/vhost-device) software. I have described the whole issue in https://github.com/rust-vmm/vhost-device/issues/613 , but it is QEMU related, and therefore I describe it here as well. +The broader context is described in https://stackoverflow.com/questions/75906208/how-to-connect-via-virtio-gui-running-on-host-with-gpio-in-a-qemu-emulated-virtu . +Steps to reproduce: +1. For Debian/testing you need to compile a libgpiod-2.1.1 (I assume that the following is done in the home directory directory of the `dev` user: `/home/dev`): + + ``` + wget https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/snapshot/libgpiod-2.1.tar.gz ; \ + tar -xzf libgpiod-2.1.tar.gz ; \ + cd libgpiod-2.1 ; \ + autoupdate ; \ + ./autogen.sh ; \ + make + ``` + 2. Download the vhost-device-gpio (`git clone https://github.com/rust-vmm/vhost-device.git`) + 3. Build the vhost-device-gpio (in the `vhost-device-gpio` subdirectory) + + ``` + export PATH_TO_LIBGPIOD=/home/dev/libgpiod-2.1 + export SYSTEM_DEPS_LIBGPIOD_NO_PKG_CONFIG=1 + export SYSTEM_DEPS_LIBGPIOD_SEARCH_NATIVE="${PATH_TO_LIBGPIOD}/lib/.libs/" + export SYSTEM_DEPS_LIBGPIOD_LIB=gpiod + export SYSTEM_DEPS_LIBGPIOD_INCLUDE="${PATH_TO_LIBGPIOD}/include/" + cargo build --features "mock_gpio" + ``` + 4. Start vhost-device-gpio: (`LD_LIBRARY_PATH=/home/emb/libgpiod-2.1/lib/.libs/ ./vhost-device-gpio -s /tmp/gpio.sock -l s4`) + 5. Download the Buildroot 2023.11.1 (`wget https://buildroot.org/downloads/buildroot-2023.11.1.tar.xz` in another directory) and unpack it. Buildroot and the main directory of Buildroot tree are denoted by BR if the following description. + 6. Configure BR (run `make qemu_aarch64_virt_defconfig` in the main BR directory, run `make menuconfig` and select external toolchain, `BR2_PACKAGE_LIBGPIOD=y`, `BR2_PACKAGE_LIBGPIOD_TOOLS=y`, run `make linux-menuconfig` and select `CONFIG_GPIO_VIRTIO=m` in the kernel configuration) + 7. Build the Linux and QEMU (run `make` in the BR directory). + 8. Run the emulation in BR/output/images, using the command line given above. + 9. After the virtual machine starts, log in as root and load the driver: `modprobe gpio-virtio` +10. Try to monitor changes of one of the emulated pins: `gpiomon 0 0` +11. You'll get the error message: + + ``` + gpiomon: error waiting for events: No such device + ``` +Additional information: +[0009-enable-F-IRQ-in-virtio-pci.patch](/uploads/39bc04b2d94063ccd539c5cfbc9cd105/0009-enable-F-IRQ-in-virtio-pci.patch) diff --git a/results/classifier/accel-gemma3:12b/vmm/2173 b/results/classifier/accel-gemma3:12b/vmm/2173 new file mode 100644 index 000000000..2268aef99 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2173 @@ -0,0 +1,2 @@ + +Disable CPU dirty region tracking on Xen + Arm64 where xen migration is not supported. diff --git a/results/classifier/accel-gemma3:12b/vmm/2179 b/results/classifier/accel-gemma3:12b/vmm/2179 new file mode 100644 index 000000000..78e0deea9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2179 @@ -0,0 +1,52 @@ + +qemu-storage-daemon: fuse export deadlock +Steps to reproduce: +1. Start QSD +2. Issue a `block-stream` and a read from the fuse export at the same time + +``` +Term 1: +(QEMU) block-stream device=root job-id=job1 +{"return": {}} +(QEMU) +{'timestamp': {'seconds': 1708386076, 'microseconds': 965781}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'created', 'id': 'job1'}} +{'timestamp': {'seconds': 1708386076, 'microseconds': 965838}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'running', 'id': 'job1'}} +(QEMU) +(QEMU) +(QEMU) +(QEMU) query-block-jobs + +<HANGS> + + +Term 2: +dd if=/tmp/fuse_exp of=/dev/null bs=1M skip=2000 +<HANGS> +``` + +``` +$ pidof qemu-storage-daemon + 92313 +$ sudo cat /proc/92313/task/92313/stack +[<0>] do_sys_poll+0x4e1/0x5d0 +[<0>] __x64_sys_ppoll+0xe2/0x170 +[<0>] do_syscall_64+0x64/0xe0 +[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 + +$ sudo cat /proc/92313/task/92314/stack +[<0>] futex_wait_queue+0x63/0x90 +[<0>] __futex_wait+0x14f/0x1c0 +[<0>] futex_wait+0x77/0x110 +[<0>] do_futex+0xcb/0x190 +[<0>] __x64_sys_futex+0x129/0x1e0 +[<0>] do_syscall_64+0x64/0xe0 +[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 +``` +Additional information: +This might also be a general between `block-stream` and `copy-on-read` but I could only trigger the problem with FUSE and not NBD. E.g this command does not deadlock: +``` +--export type=nbd,id=nbd-root,node-name=root_crw,name=root_crw,writable=off + +nbdfuse /tmp/tmp.69dRvNXj1O/disk nbd://localhost:10809/root_crw +dd if=/tmp/tmp.69dRvNXj1O/disk of=/dev/null bs=1M skip=2000 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2188 b/results/classifier/accel-gemma3:12b/vmm/2188 new file mode 100644 index 000000000..e2808bd02 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2188 @@ -0,0 +1,11 @@ + +virtio_gpu_gl_update_cursor_data() ignores the cursor resource's pixel format +Description of problem: +The function virtio_gpu_gl_update_cursor_data() ignores the pixel format of the resource it's reading from. It literally uses memcpy() to copy the pointer data. This works just fins if both the guest OS and the display backend use the same pixel format. + +The SDL backend seems to use a different pixel format to the GTK display backend. So, you'll get the correct colours in one, but not the other. +Steps to reproduce: +1. Run a VM using Virtio GPU using the GTK backend. Set the guest OS' mouse pointer to one that's red instead of white, and note the mouse pointer's actual colour +2. Now run the same VM using the SDL display backend. Check the colour of the mouse pointer (that should be red) + +NOTE: The choice of guest OS shouldn't matter. diff --git a/results/classifier/accel-gemma3:12b/vmm/2195 b/results/classifier/accel-gemma3:12b/vmm/2195 new file mode 100644 index 000000000..f921febd8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2195 @@ -0,0 +1,40 @@ + +qemu-system-x86_64 : cannot resume from S3 suspend for Q35 + OVMF +Description of problem: +There is a specific configuration where the resume from S3 does not work: + +- Q35 machine + OVMF.fd (https://retrage.github.io/edk2-nightly/) +- TCG acceleration (it works when --accel=kvm is set) + +The output at resume is: + +``` +!!!! X64 Exception Type - 05(#BR - BOUND Range Exceeded) CPU Apic ID - 00000000 !!!! +RIP - 0000000000006237, CS - 0000000000000028, RFLAGS - 0000000000000002 +RAX - 0000000080000027, RCX - 0000000000000000, RDX - 0000000000000000 +RBX - 0000000099200000, RSP - 000000000FF96236, RBP - 000000000FF96320 +RSI - 000000000F74E000, RDI - 0000000000833F31 +R8 - 0000002800000000, R9 - 0000000000000000, R10 - 000000000FF968F0 +R11 - 0000000000828B30, R12 - 000000000FF9ACD0, R13 - 000000000F76B000 +R14 - 000000000F76A000, R15 - 0000000000000000 +DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 +GS - 0000000000000030, SS - 0000000000000030 +CR0 - 0000000080000033, CR2 - 0000000000000000, CR3 - 000000000F75B000 +CR4 - 0000000000000668, CR8 - 0000000000000000 +DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 +DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 +GDTR - 0000000000833DE0 0000000000000047, LDTR - 0000000000000000 +IDTR - 000000000FF97D70 000000000000021F, TR - 0000000000000000 +FXSAVE_STATE - 000000000FF95E90 +!!!! Can't find image information. !!!! +``` + +After bisecting, this is caused by commit : 18a536f1f8d6222e562f59179e837fdfd8b92718 If i revert this comment, the resume works nicely. + +I used a script to generate a tiny initrd to test but i think the problem can be reproduced with any guest kernel + rootfs. I also verify that this problem can be reproduced with different host kernels (6.5) than the one i used (6.8) +Steps to reproduce: +1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img +2. Run qemu and drop into shell +3. Put machine into S3 (echo mem \> /sys/power/state) +4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup) +5. The machine does not resume correctly diff --git a/results/classifier/accel-gemma3:12b/vmm/2201 b/results/classifier/accel-gemma3:12b/vmm/2201 new file mode 100644 index 000000000..cbf210028 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2201 @@ -0,0 +1,12 @@ + +Windows 11 Guests ExtendedDesktopSize Not Working +Description of problem: +Windows 11 VM with the latest virtio-win drivers installed (v0.1.240) does not respond to remote resize requests. +Steps to reproduce: +1. Create a Windows 11 VM with virtio-win drivers installed and virtio video enabled. +2. Create a VNC session with resizeSession enabled. +3. Try resizing the window. +Additional information: +The resolution can be resized within the VM itself (i.e., from display settings), just doesn't automatically resize when the viewing window changes. Other VMs (including Windows 10) created and viewed within the same setup do change with the window resize. + +The Chrome console log has a number of `Server did not accept resize request: Unknown reason` errors in it. diff --git a/results/classifier/accel-gemma3:12b/vmm/2204 b/results/classifier/accel-gemma3:12b/vmm/2204 new file mode 100644 index 000000000..bd3000679 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2204 @@ -0,0 +1,74 @@ + +Hyper-V on Windows Server 2022 cannot load images converted from OVA to VHDX by qemu-img: Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device +Description of problem: +We have reference OVA image: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova and we want to convert it to VMDX format. +Steps to reproduce: +I downloaded reference OVA and converted it to VMDX with three possible options. + +With subformat dynamic: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=dynamic fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +And without it: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +And with explicitly setting fixed: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=fixed fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +In all cases I tried loading images using VM of Generation 1 and Generation 2: +``` +The application encountered an error while attempting to change the state of +'New Virtual Machine'. + +'New Virtual Machine' failed to start. + +Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.. + +Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.hdx''. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.. + +Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.vhdx'. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.'. +``` + +I noticed some similarities with https://gitlab.com/qemu-project/qemu/-/issues/136 and applied workaround to fix it: +``` +fsutil sparse setflag fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx 0 +``` + +It started complaining that file is being used by another app. I waited long enough and then rebooted server. + +After that error changed to: +``` +Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device_ +``` + +As image: + + + +For Generation 2 error is slightly different: +``` +Virtual Machine Boot Summary +1. SCSI Disk +(0,0) +The boot loader did not load an operating system. +2. Network Adapter (00155D01770C) +A boot image was not found. +``` + +As image:  + +I tried doing conversion from VirtualBox with same OVA and it worked just fine: +``` +VBoxManage clonehd fastnetmon-ubuntu-22.04-amd64-disk1.vmdk fastnetmon.vhd --format vhd +``` + +I believe something is wrong with boot records for VMDX images. + +Example of converted VHDX with dynamic flag can be found here: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.356.0.vhdx + +By Pavel Odintsov at FastNetMon.com diff --git a/results/classifier/accel-gemma3:12b/vmm/2218 b/results/classifier/accel-gemma3:12b/vmm/2218 new file mode 100644 index 000000000..b7d3bca30 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2218 @@ -0,0 +1,13 @@ + +MIDI playback issue on Windows 98 / 2000 / XP guest +Description of problem: +In Windows 98 / 2000 / XP guest, playback MIDI using Windows Media Player will cause audio slow. + +In Windows 98 / 2000 / XP guest, playback MP3 or WMA or WAV using Windows Media Player is works OK. +Steps to reproduce: +1. In Windows XP guest, open C:\WINDOWS\Media\Flourish.mid using Windows Media Player. +2. In Windows XP guest, open C:\WINDOWS\System32\OOBE\images\title.wma using Windows Media Player. +3. In Windows 98 guest, open C:\WINDOWS\Media\Passport.mid using Windows Media Player. +4. In Windows 98 guest, open C:\WINDOWS\Application Data\Microsoft\WELCOME\WELCOM98.WAV using Windows Media Player. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2224 b/results/classifier/accel-gemma3:12b/vmm/2224 new file mode 100644 index 000000000..093302c7e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2224 @@ -0,0 +1,206 @@ + +OpenBSD 7.4+ does not boot on sbsa-ref with Neoverse-V1/N2 or max cpu core +Description of problem: +System boots and then hangs: + +``` +disks: sd0* +>> OpenBSD/arm64 BOOTAA64 1.18 +boot> +cannot open sd0a:/etc/random.seed: No such file or directory +booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1 +3d5cf8 +FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. +Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org + +OpenBSD 7.4 (RAMDISK) #2131: Sun Oct 8 13:35:40 MDT 2023 + deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK +real mem = 1066156032 (1016MB) +avail mem = 996659200 (950MB) +random: boothowto does not indicate good seed +mainbus0 at root: ACPI +psci0 at mainbus0: PSCI 1.1, SMCCC 1.4 +efi0 at mainbus0: UEFI 2.7 +efi0: EFI Development Kit II / SbsaQemu rev 0x10000 +smbios0 at efi0: SMBIOS 3.4.0 +smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024 +smbios0: QEMU QEMU SBSA-REF Machine +cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3 +cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache +cpu0: 0KB 64b/line 8-way L2 cache +cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR +agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller" +agintcmsi0 at agintc0 +agtimer0 at mainbus0: 62500 kHz +acpi0 at mainbus0: ACPI 6.0 +acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +acpimcfg0 at acpi0 +acpimcfg0: addr 0xf0000000, bus 0-255 +acpiiort0 at acpi0 +pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33 +pluart0: console +ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0 +ahci0: port 0: 1.5Gb/s +scsibus0 at ahci0: 32 targets +sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_ +sd0: 43MB, 512 bytes/sector, 88064 sectors, thin +xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0 +usb0 at xhci0: USB revision 3.0 +uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 +acpipci0 at acpi0 PCI0 +pci0 at acpipci0 +0:1:0: rom address conflict 0xfffc0000/0x40000 +0:2:0: rom address conflict 0xffff8000/0x8000 +"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured +em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56 +"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +simplefb0 at mainbus0: 1280x800, 32bpp +wsdisplay0 at simplefb0 mux 1 +wsdisplay0: screen 0 added (std, vt100 emulation) +``` + +If I use Neoverse-N1 (sbsa-ref default core type) then it boots into installer: + +``` +disks: sd0* +>> OpenBSD/arm64 BOOTAA64 1.18 +boot> +cannot open sd0a:/etc/random.seed: No such file or directory +booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1 +3d5cf8 +FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. +Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org + +OpenBSD 7.4 (RAMDISK) #2131: Sun Oct 8 13:35:40 MDT 2023 + deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK +real mem = 1066156032 (1016MB) +avail mem = 996659200 (950MB) +random: boothowto does not indicate good seed +mainbus0 at root: ACPI +psci0 at mainbus0: PSCI 1.1, SMCCC 1.4 +efi0 at mainbus0: UEFI 2.7 +efi0: EFI Development Kit II / SbsaQemu rev 0x10000 +smbios0 at efi0: SMBIOS 3.4.0 +smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024 +smbios0: QEMU QEMU SBSA-REF Machine +cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r4p1 +cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache +cpu0: 1024KB 64b/line 8-way L2 cache +cpu0: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR +agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller" +agintcmsi0 at agintc0 +agtimer0 at mainbus0: 62500 kHz +acpi0 at mainbus0: ACPI 6.0 +acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +acpimcfg0 at acpi0 +acpimcfg0: addr 0xf0000000, bus 0-255 +acpiiort0 at acpi0 +pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33 +pluart0: console +ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0 +ahci0: port 0: 1.5Gb/s +scsibus0 at ahci0: 32 targets +sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_ +sd0: 43MB, 512 bytes/sector, 88064 sectors, thin +xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0 +usb0 at xhci0: USB revision 3.0 +uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 +acpipci0 at acpi0 PCI0 +pci0 at acpipci0 +0:1:0: rom address conflict 0xfffc0000/0x40000 +0:2:0: rom address conflict 0xffff8000/0x8000 +"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured +em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56 +"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +simplefb0 at mainbus0: 1280x800, 32bpp +wsdisplay0 at simplefb0 mux 1 +wsdisplay0: screen 0 added (std, vt100 emulation) +softraid0 at root +scsibus1 at softraid0: 256 targets +root on rd0a swap on rd0b dump on rd0b +WARNING: CHECK AND RESET THE DATE! +erase ^?, werase ^W, kill ^U, intr ^C, status ^T + +Welcome to the OpenBSD/arm64 7.4 installation program. +(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? +``` +Steps to reproduce: +1. download OpenBSD 7.4 image: https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img +2. download sbsa-ref firmware files from https://artifacts.codelinaro.org/ui/native/linaro-419-sbsa-ref/20240313-116475/edk2/ and decompress them +3. start qemu-system-aarch64 as shown above (adapt paths if needed) +4. watch console serial output +Additional information: +I am going to discuss this on OpenBSD mailing list. Will point to this bug. + +OpenBSD 7.5-current snapshot works on Neoverse-N1 and fails on Neoverse-V1/N2/max: + +``` +disks: sd0* +>> OpenBSD/arm64 BOOTAA64 1.18 +boot> +cannot open sd0a:/etc/random.seed: No such file or directory +booting sd0a:/bsd: 3015576+1213504+12712936+634144 [269381+91+701664+287051]=0x1 +3edee0 +FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. +Copyright (c) 1995-2024 OpenBSD. All rights reserved. https://www.OpenBSD.org + +OpenBSD 7.5 (RAMDISK) #121: Thu Mar 14 03:28:46 MDT 2024 + deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK +real mem = 1066147840 (1016MB) +avail mem = 992886784 (946MB) +random: boothowto does not indicate good seed +mainbus0 at root: ACPI +psci0 at mainbus0: PSCI 1.1, SMCCC 1.4 +efi0 at mainbus0: UEFI 2.7 +efi0: EFI Development Kit II / SbsaQemu rev 0x10000 +smbios0 at efi0: SMBIOS 3.4.0 +smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024 +smbios0: QEMU QEMU SBSA-REF Machine +cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3 +cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache +cpu0: 0KB 64b/line 8-way L2 cache +cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR,MTE +agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller" +agintcmsi0 at agintc0 +agtimer0 at mainbus0: 62500 kHz +acpi0 at mainbus0: ACPI 6.0 +acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +acpimcfg0 at acpi0 +acpimcfg0: addr 0xf0000000, bus 0-255 +acpiiort0 at acpi0 +pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33 +pluart0: console +ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0 +ahci0: port 0: 1.5Gb/s +scsibus0 at ahci0: 32 targets +sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_ +sd0: 43MB, 512 bytes/sector, 88064 sectors, thin +xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0 +usb0 at xhci0: USB revision 3.0 +uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 +acpipci0 at acpi0 PCI0 +pci0 at acpipci0 +0:1:0: rom address conflict 0xfffc0000/0x40000 +0:2:0: rom address conflict 0xffff8000/0x8000 +"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured +em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56 +"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2225 b/results/classifier/accel-gemma3:12b/vmm/2225 new file mode 100644 index 000000000..3043a4af6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2225 @@ -0,0 +1,12 @@ + +Mouse capture doesn't actually capture (GTK) +Description of problem: +The mouse is never actually captured by the window, you can always move it off screen, and because the guest OS has no awareness of the absolute mouse position there are many situations where you can't actually click something in the guest OS because the host mouse cursor is out of the window so clicking clicks on another program's window. It's unusable. + +It's clear that the problem is that the cursor isn't actually captured, if it ever was then the problem wouldn't occur. When the mouse is "uncaptured" we see the host cursor at all times and the guest cursor simply doesn't move, but when it's """captured""" the guest cursor still moves freely, it's just hidden while hovering the entire window (and not just the guest rectangle but really the whole thing) and the host cursor moves too at its own pace. + +It happens with `-display gtk` but not `-display sdl`. +Steps to reproduce: +1. Launch windowed guest +2. Click on window +3. Try to move mouse out of the window diff --git a/results/classifier/accel-gemma3:12b/vmm/2231 b/results/classifier/accel-gemma3:12b/vmm/2231 new file mode 100644 index 000000000..eeff02ae7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2231 @@ -0,0 +1,15 @@ + +GNOME/Mutter - Wayland Fractional Scaling Breaks VM Resolution +Description of problem: +VMs are rendered at a higher resolution than the pixel count of their window, seemingly because mutter is upscaling for fractional scaling. +Steps to reproduce: +1. Enable GNOME Mutter experimental fractional scaling +2. Launch VM +Additional information: +This only occurs when wayland fractional scaling is enabled, not when text is scaled. Since GNOME/mutter accomplishes fractional scaling by upscaling, I think the VM is being told its window has a higher resolution than it actually has, so it is rendering the VM at a higher resolution, which is then displayed at the display's real resolution. + +In the screenshot below, my resolution is 2256 x 1504 and I have set fractional scaling to 125%. It is worth noting (2256 / 1.25) / 3606 is approximately 0.5. + + + +I apologize if the report is unsatisfactory. I will provide more detail if instructed. I tried reporting to GNOME Boxes and Virt-manager, which both use QEMU, but it seems the problem is upstream. diff --git a/results/classifier/accel-gemma3:12b/vmm/2235 b/results/classifier/accel-gemma3:12b/vmm/2235 new file mode 100644 index 000000000..9cb2e5869 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2235 @@ -0,0 +1,58 @@ + +Hiren's Bootcd PE LiveCD not booting in windows qemu +Description of problem: +Hiren's Bootcd PE LiveCD not booting up in windows qemu. +PE stands for pre-execution environment which is like a minimal boot environment like windows-recovery. +The ram drive it makes is about 3.5 GiB. +Being able to boot something like Hiren BootCD PE is like a simple test of qemu. + +I've tried many things, but I can't figure out if it's because I can't get the arguments right or if it is because of something else. + +So far, using windows-qemu, I have not tried to boot a win10-guest-OS on win10 host-OS. +Steps to reproduce: +1. Try to start qemu as per command. Try figure out what the right arguments/options are. + +The live cd boot process is as follows +1. First the livecd bootloader loads files from the cdrom and unpacks them into a ramdrive + During this phase, in the taskmgr it can be seen that the memory of the qemu process grows to about 1.5 GiB +2. Then the boot process should transfer to the unpacked OS in the ramdrive. + In the center of the screen, if one is doing efi-boot, then one can see the tianocore logo, else if one is doing legacy boot, then one can see the windows logo. + The windows loading animation, dots in circle, does not start. In some boot attempts, it seems to have put only 1 dot, in other boot attempts nothing at all. + Even after the expansion phase, the qemu process in the taskmgr shows a 11% use (which 1 cpu in a hyperthreading i7 quadcore cpu). + This means emulator is doing something. But, despite waiting for a long time, nothing seems to happen in the guest-display-window. + +``` +PS F:\> dir D:\bootable\hb*.iso + + Directory: D:\bootable + +Mode LastWriteTime Length Name +---- ------------- ------ ---- +-a--- 9/17/2021 7:29 PM 3099203584 HBCD_PE_x64_v1.0.2_20210701.iso +-a--- 3/13/2024 4:45 PM 3291686912 HBCD_PE_x64_v1.0.8_20240305.iso + +PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso + +Algorithm Hash Path +--------- ---- ---- +SHA256 8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD D:\bootable\HBCD_PE_x64_v1.0.2_… + +PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso + +Algorithm Hash Path +--------- ---- ---- +SHA256 8C4C670C9C84D6C4B5A9C32E0AA5A55D8C23DE851D259207D54679EA774C2498 D:\bootable\HBCD_PE_x64_v1.0.8_… + +PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso.sha256 +8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD HBCD_PE_x64_v1.0.2_20210701.iso +PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso.sha256 +8c4c670c9c84d6c4b5a9c32e0aa5a55d8c23de851d259207d54679ea774c2498 HBCD_PE_x64_v1.0.8_20240305.iso +``` +Additional information: +- https://www.hirensbootcd.org/download/ +- method to create the bios file is explained in #2233 +- I have booted into v1.0.2 in native, so I know v1.0.2 works. +- I have tried qemu with and without EFI bios. +- The more recent v1.0.8 released on 20240305 is Win11 PE based (>22621) +- Virtualbox-7.0.14 is able to boot HBCDPE as normal, but with EFI disabled, and not when enabled. +- As of this issue creation, not yet checked whether under Linux if qemu-kvm can boot HBCDPE. diff --git a/results/classifier/accel-gemma3:12b/vmm/2246 b/results/classifier/accel-gemma3:12b/vmm/2246 new file mode 100644 index 000000000..456a90442 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2246 @@ -0,0 +1,2 @@ + +ppc_hv_tests.py:HypervisorTest.test_hv_pseries test fails if xorriso is not present rather than skipping diff --git a/results/classifier/accel-gemma3:12b/vmm/2251 b/results/classifier/accel-gemma3:12b/vmm/2251 new file mode 100644 index 000000000..1b09eb783 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2251 @@ -0,0 +1,15 @@ + +Windows 11 VM with VBS enabled crashes +Description of problem: + +Steps to reproduce: +1. Run a Windows 11 VM on a node (both VM domain XML and node capabilities XML is provided below). +2. Enable VBS on the guest. For doing so you can use https://github.com/MicrosoftDocs/windows-itpro-docs/files/4020040/DG_Readinessv3.7.zip. Then, in Windows terminal, run DG_Readiness_Tool_{version}.ps1 -Enable. +3. Reboot the guest. +4. Windows cannot start (see picture below). +Additional information: +- Domain Capabilities: https://pastebin.com/GdQGQ639 +- VMX capabilities: https://pastebin.com/5nbUH0ev +- contents of /proc/cpuinfo: https://pastebin.com/xZM4x89z +- Domain XML: https://pastebin.com/s4VehTXK +- Windows crash at boot: https://ibb.co/Ny1xRbz diff --git a/results/classifier/accel-gemma3:12b/vmm/2258 b/results/classifier/accel-gemma3:12b/vmm/2258 new file mode 100644 index 000000000..4172c8173 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2258 @@ -0,0 +1,24 @@ + +Breakpoint setting not working on apple Mac host +Description of problem: +1. When use with parameter "-machine virt,accel=hvf -cpu host" to run launch a emulator, it can't set breakpoint and will report error: "warning: failed to set breakpoint site at 0xffff800081bf03cc for breakpoint 1.1: error: 34 sending the breakpoint request" +but if not use with parameter "-machine virt -cpu cortex-a57"，The breakpoint can be set successfully. + +2. Set hardware breakpoint with lldb command "breakpoint set -H -a 0xFFFF800080000000" not report error, but can't hint breakpoint. I try set breakpoint on a old x86 MacOS, It will hint breakpoint successfully. + +3. I also try run qemu-system-x86_64 emulator on apple silicon mac, It also can't hint hardware breakping. The command is: +``` +qemu-system-x86_64 -machine q35,accel=tcg -smp cpus=8 \ + -kernel arch/x86/boot/bzImage \ + -append "okaslr"\ + -nographic -serial mon:stdio \ + -m 16G \ + -s -S +``` +Steps to reproduce: +1. Launch qemu on Apple silicon Mac. Remember to user "hvf" +2. Launch lldb or gdb to set breakpoint. +3. Set breakpoint and hardware breakpoint. +4. resume to run qemu by lldb. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/226 b/results/classifier/accel-gemma3:12b/vmm/226 new file mode 100644 index 000000000..c93bd7089 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/226 @@ -0,0 +1,2 @@ + +host window size does not change when guest video screen size changes while moving host window diff --git a/results/classifier/accel-gemma3:12b/vmm/2260 b/results/classifier/accel-gemma3:12b/vmm/2260 new file mode 100644 index 000000000..319cad9b3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2260 @@ -0,0 +1,26 @@ + +Storage device missing/Not recognized by driver (regression) +Description of problem: +Installation CD boots but can not find any storage/harddrive to install to. +This works in qemu 8.2.2, so it seems like a regression. +Steps to reproduce: +1. +2. +3. +Get virtio iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/ + +Install swtpm like: brew install swtpm + +Use CrystalFetch from https://docs.getutm.app/guides/windows/ to download Windows ISO. + +Create storage: qemu-img create -f qcow2 Win11.qcow2 80G + +dd if=/dev/zero of=vars-pflash.raw bs=1M count=64 + +start tpm like: /opt/homebrew/bin/swtpm socket --tpm2 --tpmstate dir=/Users/jonas/qw11arm/mytpm --ctrl type=unixio,path=/Users/jonas/qw11arm/mytpm/swtpm-sock + +start qemu like: \~/qemu/qemu/build/qemu-system-aarch64 --machine virt,virtualization=on --cpu neoverse-n1 --monitor stdio -smp cpus=4,sockets=1,cores=4,threads=1 -m 5G -device nec-usb-xhci -device qemu-xhci -device usb-kbd -device usb-tablet -device usb-storage,drive=windows,serial=windows -drive if=none,id=windows,format=raw,media=cdrom,file=/Users/jonas/ISOs/22631.2861.231204-0538.23H2_NI_RELEASE_SVC_REFRESH_CLIENTCONSUMER_RET_A64FRE_en-us.iso,readonly=on -device virtio-scsi -device scsi-hd,drive=boot,serial=boot -drive if=none,id=boot,format=qcow2,file=./Win11.qcow2 -drive if=pflash,format=raw,unit=0,file=/Users/jonas/qemu/qemu/build/pc-bios/edk2-aarch64-code.fd,readonly=on -drive file=vars-pflash.raw,format=raw,if=pflash,unit=1 -chardev socket,id=chrtpm,path=/Users/jonas/qw11arm/mytpm/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0 --display cocoa -rtc base=localtime -device ramfb -boot menu=on -device usb-storage,drive=virtio,serial=virtio -drive if=none,id=virtio,format=raw,media=cdrom,file=/Users/jonas/Downloads/virtio-win-0.1.240.iso,readonly=on -nic user,model=virtio-net-pci,mac=52:54:98:76:54:32 + +Adjust paths and be ready to bypass windows checks as described on https://docs.getutm.app/guides/windows/#this-pc-cant-run-windows-11 +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2271 b/results/classifier/accel-gemma3:12b/vmm/2271 new file mode 100644 index 000000000..10d7d2df9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2271 @@ -0,0 +1,17 @@ + +pci passthrough fails from aarch64 to amd64 guest +Description of problem: +**PCIe device Pass-thru from aarch64 host to amd64 guest fails with the below** + +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: VFIO_MAP_DMA failed: Invalid argument +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: vfio 0003:06:00.0: failed to setup container for group 25: memory listener initialization failed: Region pc.ram: vfio_dma_map(0xba4058207210, 0x100000, 0xbff00000, 0xeba70a300000) = -22 (Invalid argument) + +pass-thru with same command line syntax works correctly if the guest is aarch64 (qemu-system-aarch64). + +AMD64 guest VM otherwise works correctly if -device vfio-pci is not used. + +libvirt / virtmanager fail for aarch64 host -> amd64 guest as well. +Steps to reproduce: +1. Unbind pass-thru device from host. +2. Attach pass-thru device to vfio-pci +3. Execute qemu-system-amd64 as above. diff --git a/results/classifier/accel-gemma3:12b/vmm/2282 b/results/classifier/accel-gemma3:12b/vmm/2282 new file mode 100644 index 000000000..b66b38304 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2282 @@ -0,0 +1,2 @@ + +Corrupted output when using Intel Arc GPU with qemu+spice+virgl in headed mode diff --git a/results/classifier/accel-gemma3:12b/vmm/2287 b/results/classifier/accel-gemma3:12b/vmm/2287 new file mode 100644 index 000000000..2973051f8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2287 @@ -0,0 +1,30 @@ + +whpx, on booting win98, qemu crashes with Failed to emulate PortIO access with EmulatorReturnStatus: 2 +Description of problem: +Q) What is the correct command line arguments to boot win98se with ```accel whpx``` + +The above given command line crashes partway through the win98se boot process before the desktop shows up +``` +Windows Hypervisor Platform accelerator is operational +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: warning: GLib-GIO: Failed to open application manifest `C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppxManifest.xml' for package #34 (`Microsoft.MicrosoftEdge_44.19041.1266.0_neutral__8wekyb3d8bbwe'): error code 0x2 +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to emulate PortIO access with EmulatorReturnStatus: 2 +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor +``` +Steps to reproduce: +1. Finish a complete win98 install using ```-machine type=pc,accel=tcg -cpu qemu64``` + ```qemu-system-x86_64 -machine type=pc,accel=tcg -cpu qemu64 -smp "sockets=1,cores=1,threads=1" -m 512 -nodefaults -bios bios-256k.bin -rtc base=localtime -display sdl,gl=on -device VGA,vgamem_mb=128 -audiodev dsound,id=snd1 -device adlib,audiodev=snd1 -audiodev dsound,id=snd2 -device ac97,audiodev=snd2 -boot c -drive index=0,if=ide,media=disk,format=vhdx,file="F:\Win98m40_sys.vhdx" -drive index=1,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_01.vhdx" -drive index=3,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_02.vhdx"``` + With all guestos-win98-drivers installed the win98 seems to work satisfactorily. + Using vga driver from https://github.com/JHRobotics/vmdisp9x/releases +2. now change processor to ```-cpu core2duo```, it boots . This does not seem to matter, bug exists even with qemu64 +3. now change accel to ```-machine type=pc,accel=whpx ```, qemu crashes partway into boot before bringing up desktop. + with or without ```kernel-irqchip=off``` does not matter + with or without cpu arguments ```,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-time``` also does not matter +4. Setting back to ```-machine type=pc,accel=tcg -cpu core2duo``` restores bootable win98se. +Additional information: +- [target/i386/whpx/whpx-all.c#L920](https://gitlab.com/qemu-project/qemu/-/blob/a12214d1c4204d2f51d8724993b8dfcf50dd7d94/target/i386/whpx/whpx-all.c#L920) +- The part of the OS bootsequence, which includes the Win98/DOS boot menu, scandisk, etc. works fine. Its possible to boot to DOS mode and run DOS commands. The crash happens when into the win.com Win98SE boot sequence just before it can bring up the GUI desktop. +- qemu crashes even if in the win98/DOS bootmenu, selection is made to boot into ```safe-mode```, which is supposed to boot a vanilla 16-color VGA desktop loading minimal drivers. As before, crash happens before GUI desktop is loaded. +- 20220623 Learn.Microsoft WHvEmulatorTryIoEmulation and WHvEmulatorTryMmioEmulation + https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation +- 20220426 Learn.Microsoft WHV_EMULATOR_STATUS + https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatorstatus diff --git a/results/classifier/accel-gemma3:12b/vmm/2292 b/results/classifier/accel-gemma3:12b/vmm/2292 new file mode 100644 index 000000000..2cbd890b6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2292 @@ -0,0 +1,20 @@ + +UNIX socket path is too long +Description of problem: +At [Unikraft](https://unikraft.org) we facilitate the construction and also runtime lifecycle management of ultra-lightweight virtual machine unikernels. We have developed [`kraft`](https://github.com/unikraft/kraftkit), an open-source tool which facilitates this across a number of different virtual machine monitors, [including QEMU](https://github.com/unikraft/kraftkit/tree/staging/machine/qemu). + +We are receiving increased reports of the following error from our users: + +``` +could not start and wait for QEMU process: qemu-system-x86_64: -qmp unix:/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock,server,nowait: UNIX socket path '/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock' is too long +``` + +We systematically build the relevant QEMU process command line and arguments with flags [via our Go SDK](https://github.com/unikraft/kraftkit/blob/staging/machine/qemu/v1alpha1.go#L180-L229) and include what has become an erroneously long UNIX path for the QAPI control socket which we use to manage instantiated VM instances. + +This issue tracks the increasing of maximum path length for the `-qmp` (and maybe other) flags which accept paths. +Steps to reproduce: +1. Install [`kraft`](https://github.com/unikraft/kraftkit), [Unikraft](https://unikraft.org)'s companion command-line client; +2. Update KraftKit's config file to include an arbitrarily long path for `runtime_dir` by editing `~/.config/kraftkit/config.yaml`; +3. Start a QEMU unikernel instance with `kraft run --arch x86_64 --plat qemu unikraft.org/helloworld:latest` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2294 b/results/classifier/accel-gemma3:12b/vmm/2294 new file mode 100644 index 000000000..e0b19d459 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2294 @@ -0,0 +1,2 @@ + +x86 microvm machine stuck under Xen accelerator diff --git a/results/classifier/accel-gemma3:12b/vmm/2298 b/results/classifier/accel-gemma3:12b/vmm/2298 new file mode 100644 index 000000000..a76928ef5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/231 b/results/classifier/accel-gemma3:12b/vmm/231 new file mode 100644 index 000000000..acb476a53 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/231 @@ -0,0 +1,2 @@ + +Many leaks from qemu_spice_create_update diff --git a/results/classifier/accel-gemma3:12b/vmm/2312 b/results/classifier/accel-gemma3:12b/vmm/2312 new file mode 100644 index 000000000..a27ce9c73 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2312 @@ -0,0 +1,45 @@ + +hvf_vcpu_exec isv assert with qemu-xhci device +Description of problem: +Using the qemu-xhci device with HVF on darwin-aarch64 causes [this assert](https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1920) to fire. + +``` +travis@gmachine vms % cat launch.sh +#!/usr/bin/env bash + +~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 \ + -nographic \ + -machine virt \ + -accel hvf \ + -cpu host \ + -m 16M \ + -device qemu-xhci \ + -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin +travis@gmachine vms % ./launch.sh + + +U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000) + +DRAM: 16 MiB (effective 16 EiB) +Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1920. +./launch.sh: line 10: 22295 Abort trap: 6 ~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin +``` + +This is NixOS' build of u-boot 2024.04. This is also Nixpkgs' build of qemu-9.0.0; by default it contains some patches, but if I remove those and build with the unmodified release tarball there's no change in behavior. Naturally this doesn't happen with TCG and I haven't found any other (non-USB) device to cause this issue. +Steps to reproduce: +On a darwin-aarch64 machine with git and nix setup (8.2.2 is latest in Nixpkgs head, the same problem occurs with 9.0.0): + +``` +% git clone https://github.com/nixos/nixpkgs +% cd ./nixpkgs +% $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios $(nix-build -E 'with import ./default.nix {system = "aarch64-linux";}; ubootQemuAarch64')/u-boot.bin + + +U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000) + +DRAM: 16 MiB (effective 16 EiB) +Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1915. +zsh: abort $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel +``` +Additional information: +I have not yet tried other u-boot binaries. I suppose it could be u-boots fault? Eyeballing hvf.c this seems to be an unhandled case in the MMIO callback? I'm far out of my element so that could be total nonsense. diff --git a/results/classifier/accel-gemma3:12b/vmm/2314 b/results/classifier/accel-gemma3:12b/vmm/2314 new file mode 100644 index 000000000..022748a5b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2314 @@ -0,0 +1,17 @@ + +Building QEMU 9.0.0 fails on MacOS 10.15.7 (error: initializing 'NSEdgeInsets' (aka 'struct NSEdgeInsets') with an expression of incompatible type 'id') +Description of problem: +QEMU fails to compile using Homebrew on OS X 10.15.7: +``` +../ui/cocoa.m:542:18: error: initializing 'NSEdgeInsets' (aka 'struct NSEdgeInsets') with an expression of incompatible type 'id' + NSEdgeInsets insets = [[[self window] screen] safeAreaInsets]; + ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +1 error generated. +``` +Steps to reproduce: +1. Compile QEMU on OS X 10.15.7 using Homebrew +2. +3. +Additional information: +Build log +[02.make.zip](/uploads/dfb618b86984ed6cf699d94bf9d6c9e1/02.make.zip) diff --git a/results/classifier/accel-gemma3:12b/vmm/2331 b/results/classifier/accel-gemma3:12b/vmm/2331 new file mode 100644 index 000000000..dff95bed8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2331 @@ -0,0 +1,2 @@ + +(Question) There's a CLI option for the GUI option "Grab On Hover" ? diff --git a/results/classifier/accel-gemma3:12b/vmm/2337 b/results/classifier/accel-gemma3:12b/vmm/2337 new file mode 100644 index 000000000..2ed2073db --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2337 @@ -0,0 +1,63 @@ + +Os boot issues on 9p filesystem due to unix domain sockets open failure +Description of problem: +Unix filesystem API is broken, unix domain socket special files return an error at open() +Steps to reproduce: +Simple script. Tries to use netcat to get data through a local unix domain socket file +``` +#!/bin/bash + +# Cleanup target dir +[ -d ./target ] && rm -rf target +mkdir target + +# Add configuration updates +mkdir -p ./target/etc/initramfs-tools/ +echo 9p >> ./target/etc/initramfs-tools/modules +echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules + +# Add the test script +cat > ./target/test_init << EOF +#!/bin/bash + +echo "Test for unix domain sockets" + +nc -Ul /socket & +sleep 1 +echo "Sockets work" | nc -UN /socket || echo "Sockets fail" + +echo o > /proc/sysrq-trigger +sleep 999 +EOF +chmod 700 ./target/test_init + +# Create an Ubuntu 23.10 around it +echo "Creating Ubuntu target OS" +debootstrap --variant=minbase\ + --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \ + --exclude=man,bash-completion \ + mantic ./target > /dev/null || exit 1 + +# Run the test in 9p forwarded filesystem +echo "Running OS in qemu" +qemu-system-s390x \ + -m 8192 \ + -smp 4 \ + -nodefaults -nographic -no-reboot -no-user-config \ + -kernel ./target/boot/vmlinuz \ + -initrd ./target/boot/initrd.img \ + -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \ + -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \ + -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \ + -device virtio-serial-ccw -device sclpconsole,chardev=console \ + -chardev stdio,id=console,signal=off +``` +Additional information: +Test output: +``` +Test for unix domain sockets +qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory) +nc: No such device or address +nc: /socket: No such file or directory +Sockets fail +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2338 b/results/classifier/accel-gemma3:12b/vmm/2338 new file mode 100644 index 000000000..049477903 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2338 @@ -0,0 +1,2 @@ + +(Feature request) Implement the "grab-on-hover=on" CLI option on the SDL frontend diff --git a/results/classifier/accel-gemma3:12b/vmm/2344 b/results/classifier/accel-gemma3:12b/vmm/2344 new file mode 100644 index 000000000..54373be9f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2344 @@ -0,0 +1,46 @@ + +Plugin scoreboard deadlock (plugin.lock vs start_exclusive) +Description of problem: +Deadlock + +In frame 9 the thread grabs the plugin.lock, and starts to wait for other cpus to enter exclusive idle. +``` +#7 0x00005555555a1295 in start_exclusive () at ../hw/core/cpu-common.c:199 +#8 plugin_grow_scoreboards__locked (cpu=0x7fff0c2b4720) at ../plugins/core.c:238 +#9 qemu_plugin_vcpu_init_hook (cpu=0x7fff0c2b4720) at ../plugins/core.c:258 +``` + +The other thread just finished a TB and do the callback to the plugin, so it will not become exclusive idle until it finishes. +That callback tries to create a new 'scoreboard', but plugin.lock is already taken. +``` +#7 qemu_plugin_scoreboard_new (element_size=element_size@entry=8) at ../plugins/api.c:464 +#8 0x00007ffff7fb973d in vcpu_tb_trans (id=<optimized out>, tb=0x555555858d60) at /home/rehn/source/qemu/contrib/plugins/hotblocks.c:125 +#9 0x00005555557394f1 in qemu_plugin_tb_trans_cb (cpu=<optimized out>, tb=0x555555858d60) at ../plugins/core.c:418 +``` + +Locally I'm using this fix, reverse order so we enter exclusive idle before grabbing the plugin.lock: +``` +diff --git a/plugins/core.c b/plugins/core.c +index 1e58a57bf1..0e41c4ef22 100644 +--- a/plugins/core.c ++++ b/plugins/core.c +@@ -236,4 +236,2 @@ static void plugin_grow_scoreboards__locked(CPUState *cpu) + +- /* cpus must be stopped, as tb might still use an existing scoreboard. */ +- start_exclusive(); + struct qemu_plugin_scoreboard *score; +@@ -244,3 +242,2 @@ static void plugin_grow_scoreboards__locked(CPUState *cpu) + tb_flush(cpu); +- end_exclusive(); + } +@@ -250,2 +247,4 @@ void qemu_plugin_vcpu_init_hook(CPUState *cpu) + bool success; ++ /* cpus must be stopped, as tb might still use an existing scoreboard. */ ++ start_exclusive(); + +@@ -259,2 +258,3 @@ void qemu_plugin_vcpu_init_hook(CPUState *cpu) + qemu_rec_mutex_unlock(&plugin.lock); ++ end_exclusive(); +``` +Steps to reproduce: +Run command a few times and get 'unlucky' diff --git a/results/classifier/accel-gemma3:12b/vmm/2348 b/results/classifier/accel-gemma3:12b/vmm/2348 new file mode 100644 index 000000000..74034c7e0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2348 @@ -0,0 +1,8 @@ + +Grabbing is not possible with menu-mode disabled +Description of problem: +When starting a Qemu and bringing it into Focus, I expected Ctrl + Alt + g to enable Input Grab mode. This does not occur when the menu-bar is hidden. It does occur when the menu-bar is visible. +Steps to reproduce: +1. Open a QEMU instance in a Arch / KDE host (not fullscreen) +2. Focus the instance and attempt to enable Input Grabbing (Ctrl + Alt + G) +3. Observe that Input Grab Mode is not toggled diff --git a/results/classifier/accel-gemma3:12b/vmm/2364 b/results/classifier/accel-gemma3:12b/vmm/2364 new file mode 100644 index 000000000..bfe64b73b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2364 @@ -0,0 +1,2 @@ + +how to create two qemu instances on Windows11 so that they can access to each other in the same network? diff --git a/results/classifier/accel-gemma3:12b/vmm/2370 b/results/classifier/accel-gemma3:12b/vmm/2370 new file mode 100644 index 000000000..b50e6caec --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2370 @@ -0,0 +1,12 @@ + +[RFE] vde support on Windows +Additional information: +A vdeswitch approach can be yet another solution for #2364 . +On Windows, other methods to simultaneously bridge local qemu-VMs and allow bridge members to connect to the internet are troublesome. +Compared to MAC/Linux wherein who use kernel provided bridging. Windows users don't have it easy. + +**Ref**: +1. qemu manual for ```netdev vde``` + https://qemu.readthedocs.io/_/downloads/en/v8.2.1/pdf/#page=75 +2. virtualsquare/VDE-2 github bug Can't understand how to get it running on Windows10 64 bit ```#28``` + https://github.com/virtualsquare/vde-2/issues/28 diff --git a/results/classifier/accel-gemma3:12b/vmm/2392 b/results/classifier/accel-gemma3:12b/vmm/2392 new file mode 100644 index 000000000..2f99e425e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2392 @@ -0,0 +1,2 @@ + +Ability to use KVM on Windows diff --git a/results/classifier/accel-gemma3:12b/vmm/2398 b/results/classifier/accel-gemma3:12b/vmm/2398 new file mode 100644 index 000000000..a24a470f3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2398 @@ -0,0 +1,63 @@ + +qemu stalls when taking LUKS encrypted snapshot +Description of problem: +We have been dealing with an issue recently, where qemu occasionally stalls when taking LUKS encrypted snapshots. We were able to take several core dumps (one example below) when the issue was happening and, upon analyzing those, we found out that the issue is that the function [qcrypto_pbkdf2_count_iters](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L88) reaches an iteration number high enough that the algorithm takes a long time to finish. + +Upon investigation, we were able to see that this is happening because [start_ms and end_ms](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L115) have the same value, giving a delta of zero, causing the number of iterations to always increase. + +Here are the important parts of the coredump: + +``` +(gdb) bt +#0 0x00007fb00aba5489 in _gcry_sha256_transform_amd64_avx2 () at ../../cipher/sha256-avx2-bmi2-amd64.S:346 +#1 0x00007fb00aba3000 in sha256_final (context=0x55ab875d5028) at ../../cipher/sha256.c:591 +#2 0x00007fb00ab19dea in md_final (a=0x55ab82e1bf50) at ../../cipher/md.c:800 +#3 0x00007fb00ab19f89 in md_final (a=a@entry=0x55ab82e1bf50) at ../../cipher/md.c:1003 +#4 _gcry_md_ctl (hd=hd@entry=0x55ab82e1bf50, buflen=0, buffer=0x0, cmd=5) at ../../cipher/md.c:1012 +#5 0x00007fb00ab1a4d0 in _gcry_md_ctl (buflen=0, buffer=0x0, cmd=5, hd=0x55ab82e1bf50) at ../../cipher/md.c:1106 +#6 _gcry_md_read (hd=0x55ab82e1bf50, algo=algo@entry=0) at ../../cipher/md.c:1110 +#7 0x00007fb00ab1d9ef in _gcry_kdf_pkdf2 (passphrase=passphrase@entry=0x55ab8177f040, passphraselen=passphraselen@entry=64, hashalgo=hashalgo@entry=8, salt=salt@entry=0x55ab8397a1d4, saltlen=saltlen@entry=32, + iterations=iterations@entry=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../cipher/kdf.c:213 +#8 0x00007fb00ab1de3c in _gcry_kdf_pkdf2 (keybuffer=0x55ab817693c0, keysize=20, iterations=32768000000, saltlen=32, salt=0x55ab8397a1d4, hashalgo=8, passphraselen=64, passphrase=0x55ab8177f040) at ../../cipher/kdf.c:144 +#9 _gcry_kdf_derive (passphrase=0x55ab8177f040, passphraselen=64, algo=34, subalgo=8, salt=0x55ab8397a1d4, saltlen=32, iterations=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../cipher/kdf.c:286 +#10 0x00007fb00ab02299 in gcry_kdf_derive (passphrase=passphrase@entry=0x55ab8177f040, passphraselen=passphraselen@entry=64, algo=algo@entry=34, hashalgo=hashalgo@entry=8, salt=salt@entry=0x55ab8397a1d4, saltlen=saltlen@entry=32, + iterations=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../src/visibility.c:1337 +#11 0x000055ab7f80ff83 in qcrypto_pbkdf2 (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=nkey@entry=64, + salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, iterations=iterations@entry=32768000000, + out=0x55ab817693c0 "C[\210\003\332\017b\350\f\257\377UP\257\262\275\033\v\034(", nout=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf-gcrypt.c:75 +#12 0x000055ab7f80fe66 in qcrypto_pbkdf2_count_iters (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=64, + salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, nout=nout@entry=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf.c:80 +#13 0x000055ab7f812930 in qcrypto_block_luks_create (block=0x55ab82944540, options=<optimized out>, optprefix=<optimized out>, initfunc=0x55ab7f7abad0 <qcow2_crypto_hdr_init_func>, writefunc=0x55ab7f7ac040 <qcow2_crypto_hdr_write_func>, + opaque=0x55ab83a32290, errp=0x55ab823873d0) at ./crypto/block-luks.c:1362 +#14 0x000055ab7f810d80 in qcrypto_block_create (options=options@entry=0x55ab818e1f40, optprefix=optprefix@entry=0x55ab7f99912b "encrypt.", initfunc=initfunc@entry=0x55ab7f7abad0 <qcow2_crypto_hdr_init_func>, + writefunc=writefunc@entry=0x55ab7f7ac040 <qcow2_crypto_hdr_write_func>, opaque=opaque@entry=0x55ab83a32290, errp=errp@entry=0x55ab823873d0) at ./crypto/block.c:106 +#15 0x000055ab7f7b0f79 in qcow2_set_up_encryption (errp=0x55ab823873d0, cryptoopts=0x55ab818e1f40, bs=0x55ab83a32290) at ./block/qcow2.c:2996 +#16 qcow2_co_create (create_options=<optimized out>, errp=0x55ab823873d0) at ./block/qcow2.c:3529 +#17 0x000055ab7f7e2fca in blockdev_create_run (job=0x55ab82387350, errp=0x55ab823873d0) at ./block/create.c:46 +#18 0x000055ab7f79cf6f in job_co_entry (opaque=0x55ab82387350) at ./job.c:878 +#19 0x000055ab7f87e09c in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ./util/coroutine-ucontext.c:115 +#20 0x00007fb009a14680 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#21 0x00007ffd40716530 in ?? () +#22 0x0000000000000000 in ?? () +(gdb) frame 12 +#12 0x000055ab7f80fe66 in qcrypto_pbkdf2_count_iters (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=64, + salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, nout=nout@entry=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf.c:80 +80 if (qcrypto_pbkdf2(hash, +(gdb) info locals +ret = 18446744073709551615 +out = 0x55ab817693c0 "C[\210\003\332\017b\350\f\257\377UP\257\262\275\033\v\034(" +iterations = 32768000000 +delta_ms = <optimized out> +start_ms = 35357141 +end_ms = 35357141 +``` + +We did some investigation on the getrusage system call, which is [used to calculate start_ms and end_ms](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L72) and found some patches which indicate that it might not be that accurate: + +https://github.com/torvalds/linux/commit/3dc167ba5729ddd2d8e3fa1841653792c295d3f1 + +https://lore.kernel.org/lkml/20221226031010.4079885-1-maxing.lan@bytedance.com/t/#m1c7f2fdc0ea742776a70fd1aa2a2e414c437f534 + +So far we have only seen this with Windows guests, but it might be a red herring. It happens maybe once a month and we were unable to get a reproducer. + +I'm open to proposing a fix for this, but how could we measure this without relying on getrusage which is causing us trouble? Any other suggestions or tips on this? diff --git a/results/classifier/accel-gemma3:12b/vmm/2402 b/results/classifier/accel-gemma3:12b/vmm/2402 new file mode 100644 index 000000000..03851b2ee --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2402 @@ -0,0 +1,25 @@ + +WHPX accelerator run with edk2 EFI fails to process the reboot signal from guest OS +Description of problem: +Qemu freezes any time WHPX-accelerated guest Windows 11 sends a reboot signal to Qemu while running on edk2 EFI. At rare cases, Qemu errors out with `qemu: WHPX: Unexpected VP exit code 4` +Steps to reproduce: +1. Grab Windows 11 23H2 ISO from https://www.microsoft.com/en-Us/software-download/windows11 using either Media Creation Tool or directly and save it under C:\\windows11_23H2.iso +2. Download QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe and install it into C:\\Program Files\\qemu +3. Make one merged EFI file from two ones bundled in QEMU 9.0 (merged EFI is the only working option for edk2 EFI on windows host): `cd /d C:\Program Files\qemu\share` + +`copy /B edk2-i386-vars.fd + edk2-x86_64-code.fd edk2-x86_64.fd` + +4. Run this command: + +`qemu-system-x86_64.exe -accel whpx -bios share\edk2-x86_64.fd -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom C:\windows11_23H2.iso` + +5. Press any key once you see "Press any key to boot from CD..." and wait until Windows Setup suggests to opt for language and currency. +6. Click red "X" close button inside Windows Setup and confirm your choice when Windows Setup asks you to. + +Windows Setup sends a reboot signal to the underlying hardware and Qemu freezes. +Additional information: +If `-bios share\edk2-x86_64.fd` switch is omitted, this command works ok: + +`qemu-system-x86_64 -accel whpx -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom D:\originalWindows11_23H2.iso` + +This bug seems to be closely related to this one: https://gitlab.com/qemu-project/qemu/-/issues/2042 - Not able to reboot Linux guest on Windows host diff --git a/results/classifier/accel-gemma3:12b/vmm/2417 b/results/classifier/accel-gemma3:12b/vmm/2417 new file mode 100644 index 000000000..f99fc13f7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2417 @@ -0,0 +1,6 @@ + +qemu-img allocates full size on exFAT when metadata preallocation is requested +Description of problem: +`qemu-img` seems to preallocate the full size of a qcow2 image on exFAT rather than just the metadata when that is requested. This was initially seen via libvirt/libvirt#649. exFAT does not support sparse files. +Steps to reproduce: +1. Run command diff --git a/results/classifier/accel-gemma3:12b/vmm/2429 b/results/classifier/accel-gemma3:12b/vmm/2429 new file mode 100644 index 000000000..e4c8e658e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2429 @@ -0,0 +1,30 @@ + +Enabling SVM in guest forcefully enables hypervisor flag and doesn't respect hv-vendor-id +Description of problem: +When the SVM cpu feature is enabled in a guest; despite both the hypervisor feature being disabled and hv-vendor-id being set to AuthenticAMD, the guest hypervisor is detected as "Microsoft Hv" and the hypervisor flag is present. Whereas when the SVM cpu feature is disabled but everything else is still the same, the vendor-id is detected as "AuthenticAMD" and the hypervisor flag isn't present, which is exactly as it was intended by the parameters. Therefore, from what I can tell, enabling the SVM cpu feature (which is necessary for nested-virtualization on AMD CPUs) renders hypervisor=off and hv-vendor-id useless by forcefully enabling the hypervisor flag and setting the hypervisor's vendor-id to the default "Microsoft Hv", which normally shouldn't happen. +Steps to reproduce: +1. Run a Windows 11 virtual machine with the given CLI arguments including svm=on +2. I'm not sure how to check the hypervisor vendor from Command Prompt or PowerShell in Windows, so I used [Paranoid Fish](https://github.com/a0rtega/pafish) to check the hypervisor vendor, it's a utility for checking various different VM detection flags in a guest. +3. You should see "Hypervisor: Microsoft Hv" +Additional information: +Screenshot of Paranoid Fish with SVM enabled: + +{width="291" height="86"} ("Hypervisor:" is visible, meaning "-hypervisor" was ignored) + +{width="369" height="13"} (traced means the hypervisor bit is present, meaning `hypervisor=off` was ignored) + +And with SVM disabled: + + ("Hypervisor:" isn't visible, as intended) + +{width="339" height="12"} (OK means the hypervisor bit isn't present, as intended) + +# Solution + +I finally found a solution to this. And it looks like the problem might not even have been on QEMU's side from the beginning. First disabling Virtualization Based Security (Memory Integrity) from settings and then running the following command: `bcdedit /set hypervisorlaunchtype off` in an admin PowerShell fixes the issue and now with SVM enabled, regardless of whether Hyper-V is enabled or not, I see the following CPU information in Paranoid Fish (identical to when SVM was disabled and everything is as intended, and I can still see that virtualization is enabled in task manager): + + + + + +It looks like for some odd reason Windows enables the hypervisor bit on the CPU and sets the hypervisor's vendor-id to "Microsoft Hv" when SVM is enabled in the VM. No clue as to why it does that, but disabling Virtualization Based Security (Memory Integrity) and running the command I mentioned earlier in an admin PowerShell fixes the problem regardless. diff --git a/results/classifier/accel-gemma3:12b/vmm/2430 b/results/classifier/accel-gemma3:12b/vmm/2430 new file mode 100644 index 000000000..df4edcd81 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2430 @@ -0,0 +1,8 @@ + +allocate / free need use glibs's function. +Description of problem: +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/machine.c?ref_type=heads#L982 + +use g_free to free config,because it is allocated by g_malloc0 + +on windows,if use crt's free && glib's(DLL) g_malloc0 ,will crash. diff --git a/results/classifier/accel-gemma3:12b/vmm/2432 b/results/classifier/accel-gemma3:12b/vmm/2432 new file mode 100644 index 000000000..d0d8c135f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2432 @@ -0,0 +1,71 @@ + +Bug in bcm2835_thermal interface +Description of problem: +Stack traces, crash detail: +``` +#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:44 +#1 __pthread_kill_internal (signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:78 +#2 __GI___pthread_kill (threadid=140737230841344, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 +#3 0x00007ffff5042476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#4 0x00007ffff50287f3 in __GI_abort () at ./stdlib/abort.c:79 +#5 0x00007ffff6f0eb57 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#6 0x00007ffff6f6870f in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x0000555555d642a6 in bcm2835_thermal_write (opaque=0x7ffff0a475b0, addr=2, value=0, size=2) + at ../hw/misc/bcm2835_thermal.c:76 +#8 0x0000555556c4a119 in memory_region_write_accessor + (mr=0x7ffff0a478e0, addr=2, value=0x7fffffffd250, size=2, shift=0, mask=65535, attrs=...) + at ../system/memory.c:497 +#9 0x0000555556c49da6 in access_with_adjusted_size + (addr=2, value=0x7fffffffd250, size=2, access_size_min=1, access_size_max=4, access_fn=0x555556c49ef0 <memory_region_write_accessor>, mr=0x7ffff0a478e0, attrs=...) at ../system/memory.c:573 +#10 0x0000555556c49395 in memory_region_dispatch_write (mr=0x7ffff0a478e0, addr=2, data=0, op=MO_16, attrs=...) + at ../system/memory.c:1521 +#11 0x0000555556c84e88 in flatview_write_continue_step + (attrs=..., buf=0x7fffffffd470 "", len=512, mr_addr=2, l=0x7fffffffd360, mr=0x7ffff0a478e0) + at ../system/physmem.c:2757 +#12 0x0000555556c84c42 in flatview_write_continue + (fv=0x555559717490, addr=1059135490, attrs=..., ptr=0x7fffffffd470, len=512, mr_addr=2, l=2, mr=0x7ffff0a478e0) at ../system/physmem.c:2787 +#13 0x0000555556c73305 in flatview_write + (fv=0x555559717490, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2818 +#14 0x0000555556c73179 in address_space_write +--Type <RET> for more, q to quit, c to continue without paging--c + (as=0x5555598056f0, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2938 +#15 0x0000555556c735df in address_space_set (as=0x5555598056f0, addr=1059135490, c=0 '\000', len=2025625, attrs=...) at ../system/physmem.c:2965 +#16 0x0000555555a95b66 in rom_reset (unused=0x0) at ../hw/core/loader.c:1284 +#17 0x0000555555ab872d in legacy_reset_hold (obj=0x5555598069b0, type=RESET_TYPE_COLD) at ../hw/core/reset.c:76 +#18 0x0000555556d7dbf4 in resettable_phase_hold (obj=0x5555598069b0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:180 +#19 0x0000555556d7d19f in resettable_container_child_foreach (obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resetcontainer.c:54 +#20 0x0000555556d7f4a4 in resettable_child_foreach (rc=0x555558b02f50, obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:92 +#21 0x0000555556d7da92 in resettable_phase_hold (obj=0x5555595573d0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:169 +#22 0x0000555556d7d47a in resettable_assert_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:58 +#23 0x0000555556d7d2f7 in resettable_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:45 +#24 0x0000555555ab842e in qemu_devices_reset (reason=SHUTDOWN_CAUSE_NONE) at ../hw/core/reset.c:179 +#25 0x000055555633227d in qemu_system_reset (reason=SHUTDOWN_CAUSE_NONE) at ../system/runstate.c:493 +#26 0x0000555555aa6bd2 in qdev_machine_creation_done () at ../hw/core/machine.c:1643 +#27 0x000055555633679f in qemu_machine_creation_done (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2685 +#28 0x0000555556335ffd in qmp_x_exit_preconfig (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2715 +#29 0x000055555633bfe4 in qemu_init (argc=9, argv=0x7fffffffdc68) at ../system/vl.c:3759 +#30 0x0000555556d6eea2 in main (argc=9, argv=0x7fffffffdc68) at ../system/main.c:47 +``` +Description: +I encountered a part of the code during QEMU execution that shouldn't have been reached, which led to an error. + +Crash detail: +``` +ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached +Bail out! ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached +Aborted +``` + +Malicious inputs: +Malicious input is attached as tar.gz archive to this file, it contains file name id:000017,sig:06,src:000428,time:48261741,execs:1725363,op:havoc,rep:8 +[malicious_input.tar.gz](/uploads/fcf47faafb59308cfdb04b3e81e788f3/malicious_input.tar.gz) + +Affected code area/snippet: + +qemu/hw/misc/bcm2835_thermal.c:bcm2835_thermal_write + + +Acknowledge for reporting this issue: +Alisher Darmenov (darmenovalisher@gmail.com), +Mohamadreza Rostami (mohamadreza.rostami@trust.tu-darmstadt.de), +Ahmad-Reza Sadeghi (ahmad.sadeghi@trust.tu-darmstadt.de) diff --git a/results/classifier/accel-gemma3:12b/vmm/2437 b/results/classifier/accel-gemma3:12b/vmm/2437 new file mode 100644 index 000000000..a30f3243b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2437 @@ -0,0 +1,38 @@ + +qm terminal VMID return "Inappropriate ioctl for device" when spawned by an another process +Description of problem: +as i dont want to mess with vnc i want to use qm terminal to interact with my vms and it doesnt work im currently using nodejs as a test heres the code if anybody wanna try it +```js +import { spawn } from "child_process"; +var child = spawn('qm', ["terminal", "100"]); + +child.stdout.setEncoding('utf8'); +child.stdin.setDefaultEncoding("utf8"); +child.stdout.on('data', function (data) { + console.log('stdout: ' + data.trim()); +}); + +child.stderr.setEncoding('utf8'); +child.stderr.on('data', function (data) { + console.log('stderr: ' + data.trim()); +}); + +child.on('close', function (code) { + console.log('closing code: ' + code); +}); + +setInterval(() => { + child.stdin.write("\n"); +}, 5000); +``` +its just spawning qm terminal and sending return every 5 seconds + +it seems to start but crash + +"Inappropriate ioctl for device" + +{width=478 height=48} + +maybe its not the place to put that but i have no clue so here am i + +At least i tryed spawning something else my code is working diff --git a/results/classifier/accel-gemma3:12b/vmm/2439 b/results/classifier/accel-gemma3:12b/vmm/2439 new file mode 100644 index 000000000..df3ffcd86 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2439 @@ -0,0 +1,10 @@ + +qemu.org ssl certificate is expired +Description of problem: + +Steps to reproduce: +1. go to qemu.org +2. look at it +3. maybe screenshot +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2441 b/results/classifier/accel-gemma3:12b/vmm/2441 new file mode 100644 index 000000000..4e46594af --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2441 @@ -0,0 +1,101 @@ + +virtio-net: memory leak when hotplugging virtio-net +Description of problem: +When invalid option for virtio-net device is provided during hotplug, allocated string is not freed, leading to memory leak. +Steps to reproduce: +```sh +cat <<EOF | qemu-system-i386 -M q35 -nodefaults \ +-chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0 +quit +EOF +``` + +If above command is not working, let me know so that I provide more information. +Additional information: +There is LeakSanitizer log: + +```sh +$ cat <<EOF | LSAN_OPTIONS=fast_unwind_on_malloc=0 qemu-system-i386 -M q35 -nodefaults \ +-chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0 +quit +EOF +==831633==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +QEMU 8.1.93 monitor - type 'help' for more information +VNC server running on 127.0.0.1:5900 +(qemu) device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0 +Error: Invalid rx_queue_size (= 0), must be a power of 2 between 256 and 1024. +(qemu) quit + +================================================================= +==831633==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 15 byte(s) in 1 object(s) allocated from: + #0 0x55c1ac66b3ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x7f45c1695738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #2 0x7f45c16aa583 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x73583) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #3 0x55c1ad943dd4 in virtio_net_set_netclient_name /home/XXX/qemu/build/../hw/net/virtio-net.c:3445:25 + #4 0x55c1adace541 in virtio_net_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-net-pci.c:62:5 + #5 0x55c1ad13ec00 in virtio_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-pci.c:2228:9 + #6 0x55c1acdec557 in pci_qdev_realize /home/XXX/qemu/build/../hw/pci/pci.c:2117:9 + #7 0x55c1adcb9484 in device_set_realized /home/XXX/qemu/build/../hw/core/qdev.c:510:13 + #8 0x55c1adcd6278 in property_set_bool /home/XXX/qemu/build/../qom/object.c:2305:5 + #9 0x55c1adcd1443 in object_property_set /home/XXX/qemu/build/../qom/object.c:1435:5 + #10 0x55c1adcdd15c in object_property_set_qobject /home/XXX/qemu/build/../qom/qom-qobject.c:28:10 + #11 0x55c1adcd1d11 in object_property_set_bool /home/XXX/qemu/build/../qom/object.c:1504:15 + #12 0x55c1ad27021a in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:719:10 + #13 0x55c1ad271364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11 + #14 0x55c1ad2726eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11 + #15 0x55c1ad27311d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5 + #16 0x55c1ad3bfef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9 + #17 0x55c1ad3bdfa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9 + #18 0x55c1ad3b99ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5 + #19 0x55c1ae3d5c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13 + #20 0x55c1ad3c2261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13 + #21 0x55c1ae0ff644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9 + #22 0x7f45c168cc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #23 0x55c1ae3786db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9 + #24 0x55c1ae3786db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5 + #25 0x55c1ae3786db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11 + #26 0x55c1ad282d06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9 + #27 0x55c1adca6115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14 + #28 0x7f45c0bd0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #29 0x7f45c0bd0e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + +Direct leak of 5 byte(s) in 1 object(s) allocated from: + #0 0x55c1ac66b3ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x7f45c1695738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #2 0x7f45c16aa583 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x73583) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #3 0x55c1ad943da2 in virtio_net_set_netclient_name /home/XXX/qemu/build/../hw/net/virtio-net.c:3444:25 + #4 0x55c1adace541 in virtio_net_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-net-pci.c:62:5 + #5 0x55c1ad13ec00 in virtio_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-pci.c:2228:9 + #6 0x55c1acdec557 in pci_qdev_realize /home/XXX/qemu/build/../hw/pci/pci.c:2117:9 + #7 0x55c1adcb9484 in device_set_realized /home/XXX/qemu/build/../hw/core/qdev.c:510:13 + #8 0x55c1adcd6278 in property_set_bool /home/XXX/qemu/build/../qom/object.c:2305:5 + #9 0x55c1adcd1443 in object_property_set /home/XXX/qemu/build/../qom/object.c:1435:5 + #10 0x55c1adcdd15c in object_property_set_qobject /home/XXX/qemu/build/../qom/qom-qobject.c:28:10 + #11 0x55c1adcd1d11 in object_property_set_bool /home/XXX/qemu/build/../qom/object.c:1504:15 + #12 0x55c1ad27021a in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:719:10 + #13 0x55c1ad271364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11 + #14 0x55c1ad2726eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11 + #15 0x55c1ad27311d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5 + #16 0x55c1ad3bfef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9 + #17 0x55c1ad3bdfa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9 + #18 0x55c1ad3b99ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5 + #19 0x55c1ae3d5c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13 + #20 0x55c1ad3c2261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13 + #21 0x55c1ae0ff644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9 + #22 0x7f45c168cc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #23 0x55c1ae3786db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9 + #24 0x55c1ae3786db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5 + #25 0x55c1ae3786db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11 + #26 0x55c1ad282d06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9 + #27 0x55c1adca6115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14 + #28 0x7f45c0bd0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #29 0x7f45c0bd0e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + +SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s). +``` + +# diff --git a/results/classifier/accel-gemma3:12b/vmm/2447 b/results/classifier/accel-gemma3:12b/vmm/2447 new file mode 100644 index 000000000..bbd8f3515 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2447 @@ -0,0 +1,24 @@ + +With -display sdl,gl=on and 3D acceleration, the position of mouse does not show correctly +Description of problem: +Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px). + +Split off from https://gitlab.com/qemu-project/qemu/-/issues/761 + +VM window is not necessary to be resized to reproduce this bug. If your VM desktop comes 1920x1080 originally, the bug can be reproduced from the very start. + +Smaller resolutions show this bug too, but it not so noticeable. +Steps to reproduce: +1. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe +2. Go to https://www.kali.org/get-kali/#kali-virtual-machines and click big QEMU 64 icon, and wait till kali-linux-2024.2-qemu-amd64.7z has been downloaded +3. Extract kali-linux-2024.2-qemu-amd64.qcow2 from kali-linux-2024.2-qemu-amd64.7z +4. Run it: `qemu-system-x86_64.exe -accel tcg -device virtio-vga-gl -display sdl,gl=on -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` +5. Enter `kali` as user and `kali` as password when prompted +6. When the desktop is shown up, click the leftmost, upmost blue "Applications" button. Then click Settings -\> Display +7. Pick 1920x1080 as resolution and click Apply, then Keep this configuration. +8. Click Firefox Browser icon on the top panel. +9. When the browser starts working, experience how hard to use its interface, though it's fast. Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px). +Additional information: +Run `qemu-system-x86_64.exe -accel tcg -device virtio-vga -display sdl -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` and experience correct behavior. + +Mouse in Gtk mode works ok. OpenGL not available for Windows in GTK mode. diff --git a/results/classifier/accel-gemma3:12b/vmm/2461 b/results/classifier/accel-gemma3:12b/vmm/2461 new file mode 100644 index 000000000..2fffe521c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2461 @@ -0,0 +1,57 @@ + +Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization +Description of problem: +This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628 + +Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows. +Steps to reproduce: +1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently. + 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS. + 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2` + + To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel. + 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken. + 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit. + 6. Run `sudo dmesg | grep kvm` and note: + + `[1.924036] kvm_amd: Nested Virtualization enabled` + + `[1.924038] kvm_amd: Nested Paging disabled`\ + `[1.924040] kvm_amd: PMU virtualization is disabled` + 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM. + 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error + 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears. +10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR` + + \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why. + + \ + Microsoft released useful info about how to look into Hyper-V MSR access problems:\ + WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/ +Additional information: +By default, Hyper-V manager in Windows does not allow nested virtualization.\ +To see what happens, do the following: + + 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default). + 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false` + 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output. + 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation. + 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `0`. + 6. Shut the VM down. + 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true` + 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output: + + `[2.369144] kvm: Nested Virtualization enabled` + + `[2.369146] SVM: kvm: Nested Paging enabled` + + `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled` + + `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled` + + `[2.369153] SVM: Virtual VMLOAD VMSAVE supported` + 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM. +10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error +11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS. +12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\ + booted qemu BIOS in KVM, wrmsr was successfully called. diff --git a/results/classifier/accel-gemma3:12b/vmm/2465 b/results/classifier/accel-gemma3:12b/vmm/2465 new file mode 100644 index 000000000..5c8e7b5b2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2465 @@ -0,0 +1,2 @@ + +QEMU does not stop other threads when hitting a breakpoint diff --git a/results/classifier/accel-gemma3:12b/vmm/2466 b/results/classifier/accel-gemma3:12b/vmm/2466 new file mode 100644 index 000000000..226b9f5f0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2466 @@ -0,0 +1,25 @@ + +I'm not sure. But I Think I could cause the err(include/qemu/queue.h). +Description of problem: +At file "include/qemu/queue.h", Maybe I Think QTAILQ_REMOVE could cause a Error. + +``` +#define QTAILQ_REMOVE(head, elm, field) do { \ + if (((elm)->field.tqe_next) != NULL) \ + (elm)->field.tqe_next->field.tqe_circ.tql_prev = \ + (elm)->field.tqe_circ.tql_prev; \ + else \ + (head)->tqh_circ.tql_prev = (elm)->field.tqe_circ.tql_prev; \ + (elm)->field.tqe_circ.tql_prev->tql_next = (elm)->field.tqe_next; \ + (elm)->field.tqe_circ.tql_prev = NULL; \ + (elm)->field.tqe_circ.tql_next = NULL; \ + (elm)->field.tqe_next = NULL; \ +} while (/*CONSTCOND*/0) +``` +If the length of the que is one, line 7 cause a segmentation fault. +Steps to reproduce: +1. Create a Que with QTAILQ_INIT +2. Add one element to que. +3. Remove the element with QTAILQ_REMOVE +Additional information: +queue.h file is located at "inclue/qemu/queue.h" diff --git a/results/classifier/accel-gemma3:12b/vmm/2480 b/results/classifier/accel-gemma3:12b/vmm/2480 new file mode 100644 index 000000000..d4049ddfe --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2480 @@ -0,0 +1,30 @@ + +Two questions about VFIO device live migration +Description of problem: +For my own pcie device, i implement system memory && device memory dirty bitmap track and works well + +use pre-copy mode live migration by the way. + +first question: +- for system memory dirty bitmap sync, notice that last sync will come early than i expected + read qemu code and found qemu will call every savevm_state.handlers->save_live_complete_precopy callback + in "qemu_savevm_state_complete_precopy_iterable", and "vfio" handler will always behind "ram". + so here is question, my own vfio device will only be halted after "vfio" handler enter + save_live_complete_precopy, and last system memory dirty bitmap sync will come with "ram"'s + save_live_complete_precopy, there will be some system dirty between this period, should we add one more + system dirty bitmap sync after "vfio"'s save_live_complete_precopy + +second question: +- notice that qemu will clean up migration and call every savevm_state.handlers->save_cleanup call back, and + in this function, qemu will only call vfio listener's log_global_stop call back when vm_is_running + but for my vfio device, state will be paused(postmigrate) when enter here, so there is no chance for qemu + to relese some resource create by my device kernel mode driver, where should i put the logic about "stop + migration resource" anyway + +Thanks ^_^ +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2482 b/results/classifier/accel-gemma3:12b/vmm/2482 new file mode 100644 index 000000000..fb427300d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2482 @@ -0,0 +1,137 @@ + +qemu-system-x86_64: Live Migration fails with BLOCK_JOB_ERROR +Description of problem: +After disk migration is completed and RAM migration is being performed, migration status switches to 'pre-switchover'. +In the 'pre-switchover' migration state, block jobs status is still set to 'ready' instead of 'running' +on queried for block job status when 'offset' and 'length' diverged. Thus, It results in BLOCK_JOB_ERROR. +Steps to reproduce: +On source host +1. Add disk(s) that needed to be migrated by issuing 'blockdev-add' QMP command. +2. start blockdev-mirror operations to perform disk(s) transfer by issuing QMP command +3. start RAM migration. (send HMP commands - listed below +4. Migration status changed to 'pre-switchover'. While in 'pre-switchover', check for disk activity + +While RAM migration is happening, Migration status is changed to 'pre-switchover' +and observe that block jobs 'offset' and 'length' diverged. But, block job status is still set to 'ready' instead of 'running'. + +On destination host +1. Launch the VM in listening mode (-incoming) for migrations +2. start NBD server +3. add disks to NBD server. +4. set migration parameters by sending HMP commands +Additional information: +# On SOURCE Host, start all blockdev-add operations +# Issue QMP commands (blockdev-add) for all block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") of VM + +``` + { + "execute" => "blockdev-add", + "arguments" => { + "driver" => "raw", + "node-name" => "node_drive-scsi-disk-0", + "auto-read-only" => false, + "read-only" => false, + "file" => { + "driver" => "nbd", + "export" => "drive-scsi-disk-0", + "server" => { + "type" => "inet", + "host" => "2600:3c0f:17:14::21", + "port" => "37552", + }, + "tls-creds" => "tlscreds0" + } + } + } +``` + + { + "execute" => "blockdev-add", + "arguments" => { + "driver" => "raw", + "node-name" => "node_drive-scsi-disk-1", + "auto-read-only" => false, + "read-only" => false, + "file" => { + "driver" => "nbd", + "export" => "drive-scsi-disk-1", + "server" => { + "type" => "inet", + "host" => "2600:3c0f:17:14::21", + "port" => "37552", + }, + "tls-creds" => "tlscreds0" + } + } + } + +# On SOURCE Host, start all blockdev-mirror operations to start disk transfer +# i.e Issue QMP commands (blockdev-mirror) for each of those block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") + +``` + { + "execute" => "blockdev-mirror", + "arguments" => { + "device" => "drive-scsi-disk0", + "target" => "node_drive-scsi-disk-0", + "speed" => 100000000, + "sync" => "full", + } + } +``` + +``` + { + "execute" => "blockdev-mirror", + "arguments" => { + "device" => "drive-scsi-disk1", + "target" => "node_drive-scsi-disk-1", + "speed" => 100000000, + "sync" => "full", + } + } +``` + +# NBD server configuration on destination host by issuing QMP command +# Start NBD server +``` + { + "execute" => "nbd-server-start", + "arguments" => { + "addr" => { + "type" => "inet", + "data" => { + "host" => "2600:3c0f:17:14::21", + "port" => "37552" + } + }, + "tls-creds" => "tlscreds0" + } + } +``` + +# On DESTINATION Host +# Register incoming disks(2) with NBD server by issuing QMP commands to VM on the destination host +# Disk# 1 +``` + { + "execute" => "nbd-server-add", + "arguments" => { + "device" => "drive-scsi-disk0", + "writable" => true + } + } +``` +# Disk# 2 +``` + { + "execute" => "nbd-server-add", + "arguments" => { + "device" => "drive-scsi-disk1", + "writable" => true + } + } +``` + +# Wait for disks to finish the bulk of the data migration. +# diff --git a/results/classifier/accel-gemma3:12b/vmm/2492 b/results/classifier/accel-gemma3:12b/vmm/2492 new file mode 100644 index 000000000..21a5975b7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2492 @@ -0,0 +1,21 @@ + +Unable to disable gvnc dependency during build +Description of problem: +The qtest tests will pick up a copy of gvnc if it happens to be installed and there does not appear +to be any way of disabling the dependency to ensure a reproducible build. We tripped over this in +bulk builds on OpenBSD. +Steps to reproduce: +1. Install gvnc +2. Build QEMU +Additional information: +From tests/qtest/meson.build + +``` +if vnc.found() + gvnc = dependency('gvnc-1.0', method: 'pkg-config', required: false) + if gvnc.found() + qtests += {'vnc-display-test': [gvnc]} + qtests_generic += [ 'vnc-display-test' ] + endif +endif +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2514 b/results/classifier/accel-gemma3:12b/vmm/2514 new file mode 100644 index 000000000..915fc57e7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2514 @@ -0,0 +1,2 @@ + +network unreachable to esxi 8 guest diff --git a/results/classifier/accel-gemma3:12b/vmm/2521 b/results/classifier/accel-gemma3:12b/vmm/2521 new file mode 100644 index 000000000..cabb294d3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2521 @@ -0,0 +1,17 @@ + +USB Passthrough Improper Remote Wakeup +Description of problem: +I am doing research with Linux Power Management interactions with USB devices. Which is why I would like to be able to wake a qemu vm from suspend with a passed through USB device. The first issue is that remote wakeup from usb devices do not wake the vm at all when running in -nographic mode (issuing system_wakeup from a qemu monitor shell will wake it though). When running with a GUI it is possible to wake the vm from a usb device as well as the qemu monitor shell but both will result in the GUI screen being black afterwards. It is still possible to use the vm though. Finally, waking the vm with a usb device is only possible when a valid usb device is passed through in the qemu launch command line. But interestingly the usb device specified to be passed through will only wakeup the vm if it is unplugged and plugged back in during the suspend. All other usb devices can wakeup the vm normally even though they are not passed through. It is not clear to me what is going on here and why other devices not being passed through to qemu can wake the vm. Note I have also enabled the /sys/bus/usb/devices/usb#/power/wakeup file and have manually unsuppressed the remote_wakeup flag in the source code to enable the /sys/bus/usb/devices/#-#/power/wakeup files to be generated but it has not affected anything. +Steps to reproduce: +I have tested this issue with multiple kernel versions (6.10, 6.10-rc4, 6.6.43) as well as custom and generic kernel configs and different debian images so these do not seem to be the problem. But here is a detailed description of the exact setup I am currently using: + +1. Download linux-6.10-rc4 source and configure with syzkaller fuzzing config https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-usb.config +2. Set CONFIG_KCOV_INSTRUMENT_ALL to off (breaks suspend/resume in vm) and create bzImage +2. Create a debian bookworm image with syzkaller script https://github.com/google/syzkaller/blob/master/tools/create-image.sh +3. Download and build Qemu from source (see attached for detailed configuration and dependencies) +4. Attach a usb keyboard and mouse +5. Choose one device to pass through via command line +6. Try waking the vm with nographic and graphic mode using the usb devices +Additional information: +[configuration_output.txt](/uploads/f7d3487dab65deef40bd0e110b64a573/configuration_output.txt) +[gui_wakeup_log.txt](/uploads/72b192a88d587eced4bb4032307307e5/gui_wakeup_log.txt) diff --git a/results/classifier/accel-gemma3:12b/vmm/2530 b/results/classifier/accel-gemma3:12b/vmm/2530 new file mode 100644 index 000000000..954cdf0a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2530 @@ -0,0 +1,18 @@ + +Duplicate ACPI _SUN +Description of problem: +ACPI _SUN is `the slot-unique ID number for a slot`, but qemu uses `PCI_SLOT()` which is definitely not unique +https://gitlab.com/qemu-project/qemu/-/blob/407f9a4b121eb65166375c410e14d7b704bc1106/hw/i386/acpi-build.c#L524 +Steps to reproduce: +1. Create a linux VM with 2 virtio NICs +2. Look at the ACPI _SUN of the virtio-pci devices (firmware_node/sun) + +Both virtio-pci devices have _SUN == 0 +``` +# +Additional information: +In systemd we recently introduced code to use firmware_node/sun information for NIC naming +https://github.com/systemd/systemd/commit/0a4ecc54cb9f2d3418b970c51bfadb69c34ae9eb + +but having duplicate _SUN is of course problematic +https://github.com/systemd/systemd/issues/34082 diff --git a/results/classifier/accel-gemma3:12b/vmm/2532 b/results/classifier/accel-gemma3:12b/vmm/2532 new file mode 100644 index 000000000..c26bdc7fb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2532 @@ -0,0 +1,41 @@ + +empty vmdk disk created by qemu-img cann't import to vmware ESXi or Workstation +Description of problem: +qemu-img create empty vmdk file, and can't import to vmware workstation or ESXi. the ovftool + fail. the log: + +> ``` +> 2024-08-23T11:19:32.335+08:00 verbose OVFTool[4088548] [Originator@6876 sub=Default] Opening disk target empty-disk2.vmdk +> 2024-08-23T11:19:32.335+08:00 error OVFTool[4088548] [Originator@6876 sub=Default] Error on read, error: -1 +> 2024-08-23T11:19:32.336+08:00 verbose OVFTool[4088187] [Originator@6876 sub=Default] Exception thrown: N5boost16exception_detail10clone_implINS_17unknown_exceptionEEE(std::exception) +> 2024-08-23T11:19:32.337+08:00 verbose OVFTool[4088187] [Originator@6876 sub=Default] Backtrace: +> --> [backtrace begin] product: VMware Workstation, version: e.x.p, build: build-15722219, tag: OVFTool, cpu: x86_64, os: linux, buildType: release +> --> backtrace[00] libvmacore.so[0x003DD716] +> --> backtrace[01] libvmacore.so[0x001CF8DF]: Vmacore::System::Stacktrace::CaptureWork(unsigned int) +> --> backtrace[02] libvmacore.so[0x001B6EA9]: Vmacore::System::SystemFactory::CreateQuickBacktrace(Vmacore::Ref<Vmacore::System::Backtrace>&) +> --> backtrace[03] libvmacore.so[0x0016CF2E]: Vmacore::Throwable::Throwable(std::string&&) +> --> backtrace[04] ovftool.bin[0x001C1F38] +> --> backtrace[05] ovftool.bin[0x002008D5] +> --> backtrace[06] ovftool.bin[0x00129EF0] +> --> backtrace[07] libc.so.6[0x00044E50] +> --> backtrace[08] libc.so.6[0x00044EFC] +> --> backtrace[09] ovftool.bin[0x00132D21] +> --> [backtrace end] +> ``` + +the log file: +[test.log](/uploads/174db2ace468bd9f0ec3ab14de524217/test.log) +Steps to reproduce: +1. create empty vmdk file + +./qemu-img create -f vmdk -o adapter_type=lsilogic,subformat=streamOptimized empty.vmdk 1G + +2. add empty file info to ovf file +<File ovf:href="empty.vmdk" ovf:id="file2"/> + +3. import it to vmware workstation +Additional information: +If i write some data to empty vmdk file, it can import successfully. The reson: qemu only write metadata for empty vmdk file, but the ovftool need read more data and it cann't read more. +we can write one sector zero data after the metadata, ovftool work well. +I submitted the patch: +https://patchew.org/QEMU/20240822105237.777-1-luzhipeng@cestc.cn/ diff --git a/results/classifier/accel-gemma3:12b/vmm/2544 b/results/classifier/accel-gemma3:12b/vmm/2544 new file mode 100644 index 000000000..6f7e262ee --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2544 @@ -0,0 +1,2 @@ + +Bug: qemu not properly flushing error messages related to bad arguments diff --git a/results/classifier/accel-gemma3:12b/vmm/2551 b/results/classifier/accel-gemma3:12b/vmm/2551 new file mode 100644 index 000000000..0847254f6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2551 @@ -0,0 +1,14 @@ + +RTC time could run slow 3s than host time when clock=vm & base=UTC +Description of problem: +When start qemu with `-rtc base=utc,clock=vm`, sometime guest time can slower 3s than host. There's no problem (also didn't be noticed) as we often start ntp service, who will adjust our system time. But let's talk about if we havn't enable NTP service(for example system just booted) + +After inspect into the code, i found that there are two problem we should think about: +# +Steps to reproduce: +1. start vm with `-rtc base=utc,clock=vm` +2. disable NTP (OS specific)`systemctl disable --now ntpd;systemctl disable --now ntpdate` +3. reboot in the guest +4. after guest started, compare guest time with host time(at the same time) `date +'%F %T.%3N'` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2556 b/results/classifier/accel-gemma3:12b/vmm/2556 new file mode 100644 index 000000000..0d4553156 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2556 @@ -0,0 +1,13 @@ + +memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes) +Description of problem: +When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off. +Steps to reproduce: +1. wait until Windows has booted +2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_ +3. Shut down (or reboot) Windows + +The system shows the boot screen at shutdown for a long time. + +It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB. +So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes** diff --git a/results/classifier/accel-gemma3:12b/vmm/2571 b/results/classifier/accel-gemma3:12b/vmm/2571 new file mode 100644 index 000000000..bc346ded1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2571 @@ -0,0 +1,67 @@ + +9.1.0 spurious guest journal errors -> linux guest on AMD host +Description of problem: +Since upgrading to 9.1.0 I'm seeing new error messages (see below) inside the guest when booting linux guests on an AMD host. Bisection points to: +``` +2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6 is the first bad commit +commit 2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6 +Author: John Allen <john.allen@amd.com> +Date: Mon Jun 3 19:36:21 2024 +0000 + + i386: Add support for SUCCOR feature + + Add cpuid bit definition for the SUCCOR feature. This cpuid bit is required to + be exposed to guests to allow them to handle machine check exceptions on AMD + hosts. +``` +Everything still seems to work so possibly not a bug. But the errors are still very disconcerting. Any thoughts? +Steps to reproduce: +1. e.g. Boot linux with `-cpu host` on an AMD host +Additional information: +``` +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: unchecked MSR access error: RDMSR from 0x852 at rIP: 0xffffffffb548ffa7 (native_read_msr+0x7/0x40) +Sep 14 12:02:53 kernel: Call Trace: +Sep 14 12:02:53 kernel: <TASK> +Sep 14 12:02:53 kernel: ? ex_handler_msr.isra.0.cold+0x28/0x60 +Sep 14 12:02:53 kernel: ? fixup_exception+0x157/0x380 +Sep 14 12:02:53 kernel: ? gp_try_fixup_and_notify+0x1e/0xb0 +Sep 14 12:02:53 kernel: ? exc_general_protection+0x104/0x400 +Sep 14 12:02:53 kernel: ? asm_exc_general_protection+0x26/0x30 +Sep 14 12:02:53 kernel: ? native_read_msr+0x7/0x40 +Sep 14 12:02:53 kernel: native_apic_msr_read+0x20/0x30 +Sep 14 12:02:53 kernel: setup_APIC_eilvt+0x47/0x110 +Sep 14 12:02:53 kernel: mce_amd_feature_init+0x485/0x4e0 +Sep 14 12:02:53 kernel: mcheck_cpu_init+0x1bb/0x470 +Sep 14 12:02:53 kernel: identify_cpu+0x396/0x5e0 +Sep 14 12:02:53 kernel: arch_cpu_finalize_init+0x20/0x140 +Sep 14 12:02:53 kernel: start_kernel+0x931/0x9c0 +Sep 14 12:02:53 kernel: x86_64_start_reservations+0x24/0x30 +Sep 14 12:02:53 kernel: x86_64_start_kernel+0x95/0xa0 +Sep 14 12:02:53 kernel: common_startup_64+0x13e/0x141 +Sep 14 12:02:53 kernel: </TASK> +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 0, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 2, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 4, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 6, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: #1 #3 #5 #7 +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 1, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 3, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 5, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 7, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2572 b/results/classifier/accel-gemma3:12b/vmm/2572 new file mode 100644 index 000000000..75c594829 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/2582 b/results/classifier/accel-gemma3:12b/vmm/2582 new file mode 100644 index 000000000..c09774ad0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2582 @@ -0,0 +1,24 @@ + +CR4.VMX leaks from L1 into L2 on Intel VMX +Description of problem: +In a nested virtualization setting, `savevm` can cause CR4 bits from leaking from L1 into L2. This causes general-protection faults in certain guests. + +The L2 guest executes this code: + +``` +mov rax, cr4 ; Get CR4 +mov rcx, rax ; Remember the old value +btc rax, 7 ; Toggle CR4.PGE +mov cr4, rax ; #GP! <- Shouldn't happen! +mov cr4, rcx ; Restore old value +``` + +If the guest code is interrupted at the right time (e.g. via `savevm`), Qemu marks CR4 dirty while the guest executes L2 code. Due to really complicated KVM semantics, this will result in L1 CR4 bits (VMXE) leaking into the L2 guest and the L2 will die with a GP: + +Instead of the expected CR4 value, the L2 guest reads a value with VMXE set. When it tries to write this back into CR4, this triggers the general protection fault. +Steps to reproduce: +This is only an issue on **Intel** systems. + +# +Additional information: +See also this discussion where we discussed a (flawed) approach to fixing this in KVM: https://lore.kernel.org/lkml/Zh6WlOB8CS-By3DQ@google.com/t/ diff --git a/results/classifier/accel-gemma3:12b/vmm/2584 b/results/classifier/accel-gemma3:12b/vmm/2584 new file mode 100644 index 000000000..f650c1c2a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2584 @@ -0,0 +1,17 @@ + +nbd URI wrong export name (regression in qemu 9.1) +Description of problem: +qemu with an nbd URI seems to pass the wrong export name to the server, if the exportname is `.`. This seems +to be a regression in qemu 9.1, because it didn't happen in 9.0. +Steps to reproduce: +``` +$ nbdkit -fv -U - null --run 'qemu-img info "nbd+unix:///.?socket=$unixsocket"' +... +nbdkit: null[1]: debug: null: open readonly=0 exportname="" tls=0 +``` + +In qemu 9.0 this was correct: + +``` +nbdkit: null[1]: debug: null: open readonly=0 exportname="." tls=0 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2593 b/results/classifier/accel-gemma3:12b/vmm/2593 new file mode 100644 index 000000000..8f78c65ec --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2593 @@ -0,0 +1,58 @@ + +-netdev user,smb=/path doesn't work with old Windows versions anymore +Description of problem: +I'm running Windows 98 in qemu and wasn't able to access the share. After finding `/tmp/qemu-smb.*/` and increasing the log level (setting `log level = 10` in the temporary smb.conf) it became clear, that the smbd server didn't support any of the protocols offered by Win98: + +<details> + +``` +[2024/09/25 23:04:25.871072, 10, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../lib/util/util.c:580(dump_data) + [0000] 02 50 43 20 4E 45 54 57 4F 52 4B 20 50 52 4F 47 .PC NETW ORK PROG + [0010] 52 41 4D 20 31 2E 30 00 02 4D 49 43 52 4F 53 4F RAM 1.0. .MICROSO + [0020] 46 54 20 4E 45 54 57 4F 52 4B 53 20 33 2E 30 00 FT NETWO RKS 3.0. + [0030] 02 44 4F 53 20 4C 4D 31 2E 32 58 30 30 32 00 02 .DOS LM1 .2X002.. + [0040] 44 4F 53 20 4C 41 4E 4D 41 4E 32 2E 31 00 02 57 DOS LANM AN2.1..W + [0050] 69 6E 64 6F 77 73 20 66 6F 72 20 57 6F 72 6B 67 indows f or Workg + [0060] 72 6F 75 70 73 20 33 2E 31 61 00 02 4E 54 20 4C roups 3. 1a..NT L + [0070] 4D 20 30 2E 31 32 00 M 0.12. +[2024/09/25 23:04:25.871241, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [PC NETWORK PROGRAM 1.0] +[2024/09/25 23:04:25.871247, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [MICROSOFT NETWORKS 3.0] +[2024/09/25 23:04:25.871252, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [DOS LM1.2X002] +[2024/09/25 23:04:25.871256, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [DOS LANMAN2.1] +[2024/09/25 23:04:25.871260, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [Windows for Workgroups 3.1a] +[2024/09/25 23:04:25.871264, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [NT LM 0.12] +... +[2024/09/25 23:04:25.871315, 6, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../source3/param/loadparm.c:2442(lp_file_list_changed) + lp_file_list_changed() + file /tmp/qemu-smb.TU2YU2/smb.conf -> /tmp/qemu-smb.TU2YU2/smb.conf last mod_time: 2024-09-25 23:04:20.374500597 +[2024/09/25 23:04:25.871325, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1201(smb2_multi_protocol_reply_negprot) + smb2_multi_protocol_reply_negprot: No protocol supported ! + +``` + +</details> + +(`smb2_multi_protocol_reply_negprot: No protocol supported !`). + +Manually adding the line `server min protocol = LANMAN1` under `[global]` in the temporary `smb.conf` fixed the issue. +I think qemu should add that line by default. + +The behavior was the same with smbd 4.15.13-Ubuntu from Ubuntu 22.04 and 4.21.0 from current Arch Linux. +Steps to reproduce: +1. Set up qemu VM with Win98 (or presumably any Windows version up to XP) + * at least on my machine I had to use `tcg`, with `kvm` Win98 is very unstable on Ryzen CPUs + * I roughly followed this tutorial: https://computernewb.com/wiki/QEMU/Guests/Windows_98 incl. using that Windows 98 QuickInstall ISO and the softgpu driver + * enable user-mode networking with smb share (`-netdev user,id=lan,smb=/path/to/share -device pcnet,netdev=lan`) +2. Edit `C:\Windows\LMHOSTS` as described in the qemu documentation (add line `10.0.2.4 smbserver`) +3. Probably reboot the Windows VM + * Actually, rebooting Win98 doesn't work for me, it then hangs while booting. Shutting down and starting the VM again works though. +4. Open the Windows Explorer and enter `\\smbserver` in the address bar - it will fail with some unhelpful error. +5. Edit `/tmp/qemu-smb.*/smb.conf` and add the line `server min protocol = LANMAN1` under `[global]` + - `server min protocol = NT1` also works for Win98, but with `LANMAN1` even older operating systems like Win3.11 should also work +6. Retry step 4 - it should work now. diff --git a/results/classifier/accel-gemma3:12b/vmm/2602 b/results/classifier/accel-gemma3:12b/vmm/2602 new file mode 100644 index 000000000..ed16bc6ad --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2602 @@ -0,0 +1,10 @@ + +Windows installer being signed with an expired certificate +Description of problem: +Digital Signature for setup is invalid +Steps to reproduce: +1. Downloaded the latest 64-bit windows installer +2. Right Click and select Digital Signature tab +3. Observe certificate shows valid dates are 12/8/2022 - 12/9/2023 +Additional information: +{width=621 height=393} diff --git a/results/classifier/accel-gemma3:12b/vmm/2608 b/results/classifier/accel-gemma3:12b/vmm/2608 new file mode 100644 index 000000000..b354fd614 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2608 @@ -0,0 +1,10 @@ + +Black screen in Windows XP +Description of problem: +When starting the installation of Windows XP (or Windows 2003) the screen in VNC stays black while the installer is in text-mode. During the second half of the installation, where it switches to graphical GUI, the display becomes visible again. + +This problem never happened on 9.0.1 and below, so is a regression in 9.1.0 +Steps to reproduce: +1. Start the Windows XP installer +2. Connect to VNC +3. Screen stays black diff --git a/results/classifier/accel-gemma3:12b/vmm/2609 b/results/classifier/accel-gemma3:12b/vmm/2609 new file mode 100644 index 000000000..4beba3f1c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2609 @@ -0,0 +1,12 @@ + +Blue screen in Windows XP +Description of problem: +When starting the installation of Windows XP when using a virtioblk device you immediately get a bluescreen: `STOP: 0x000000A5 (0x00000002, 0x8A1A6008, 0xE1018808, 0x8A1B7F00)`. I think this happens even before it loads the SATA drivers that are slipstreamed in the ISO. + +After a lot of Googling about this error 0x000000A5 I found some posts suggesting that changing the machine type from `q35` to `pc-q35-2.10` solves the issue. And it worked. Anything above 2.10 (for example 2.11) and the bluescreens return. + +So I always used this solution, but in QEMU 9.1.0 it warns that `pc-q35-2.10` will be removed soon. This would mean there is no way anymore to install XP to a SATA disk unattendly. +Steps to reproduce: +1. Use a virtioblk disk and SATA drivers +2. Start the Windows XP installer +3. Bluescreen will appear diff --git a/results/classifier/accel-gemma3:12b/vmm/2621 b/results/classifier/accel-gemma3:12b/vmm/2621 new file mode 100644 index 000000000..1e8fb40e1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2621 @@ -0,0 +1,16 @@ + +virtgpu does not return error for misconfigured virgl command +Description of problem: +When ```virgl_renderer_submit_cmd``` reports error, cmd->error should be set. Otherwise driver cannot know if there is error. +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-virgl.c?ref_type=heads#L233 + +Probably 0x1200 (unspec) or 0x1205 (invalid param) should return as error. + + +If there is problem in cmd virgl freezes drawing window. +Steps to reproduce: +1. Send misformated command to virgl over vgpu device +2. +3. +Additional information: +Misformated 3d commands stops opengl's drawings. Without returning error we cannot know any error, hence we cannot reset vgpu. diff --git a/results/classifier/accel-gemma3:12b/vmm/2638 b/results/classifier/accel-gemma3:12b/vmm/2638 new file mode 100644 index 000000000..5a94e7f2c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2638 @@ -0,0 +1,18 @@ + +Incorrect SPDX license expression +Description of problem: +In the source code, the syntax of license expressions after the keyword SPDX-License-Identifier is not always correct. + +"GPL-2.0" should be "GPL-2.0-only" + +"GPL-2.0 WITH Linux-syscall-note" should be "GPL-2.0-only WITH Linux-syscall-note" + +"GPL-2.0+" should be "GPL-2.0-or-later" + +"GPL-2.0+ WITH Linux-syscall-note" should be "GPL-2.0-or-later WITH Linux-syscall-note" + +"GPL-v2-only" should be "GPL-2.0-only" + +"LGPL-2.1+" should be "LGPL-2.1-or-later" + +"MIT CC0-1.0" should be "MIT" diff --git a/results/classifier/accel-gemma3:12b/vmm/2639 b/results/classifier/accel-gemma3:12b/vmm/2639 new file mode 100644 index 000000000..3810d87e7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2639 @@ -0,0 +1,23 @@ + +[Regression] v9.1.1: hw/audio/hda audio output stream closes (SPICE) +Description of problem: +Beginning with QEMU 9.1.1, SPICE is unable to route audio from the guest to host. This affects `virt-viewer` as well as `Looking Glass`. Reverting packages to 9.1.0 restores functionality. + +Reported at [Arch Linux forums](https://bbs.archlinux.org/viewtopic.php?id=300475) and [Looking Glass discord](https://discord.com/channels/804108879436316733/1298405109210022038) + +---- + +I've confirmed https://gitlab.com/qemu-project/qemu/-/commit/6d03242a7e47815ed56687ecd13f683d8da3f2fe caused the regression, applying reverse patch to 9.1.1 resolves the issue +Additional information: +Debugging output from the [Looking Glass discord](https://discord.com/channels/804108879436316733/1298405109210022038/1298669405118664767): +``` +00:00:00.633 [I] main.c:1735 | lg_run | Starting session +[New Thread 0x7fffd12006c0 (LWP 10071)] +[New Thread 0x7fffc7e006c0 (LWP 10072)] +00:00:00.633 [I] main.c:553 | main_frameThread | Using DMA buffer support +00:00:01.339 [I] main.c:710 | main_frameThread | Format: FRAME_TYPE_BGRA 2560x1400 (2560x1400) stride:2560 pitch:10240 rotation:0 hdr:0 pq:0 + +Thread 2 "spiceThread" received signal SIGPIPE, Broken pipe. +[Switching to Thread 0x7fffdba006c0 (LWP 10024)] +0x00007ffff712a6ea in send () from /usr/lib/libc.so.6 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2640 b/results/classifier/accel-gemma3:12b/vmm/2640 new file mode 100644 index 000000000..80ca2d232 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2640 @@ -0,0 +1,2 @@ + +QEMU twice logging when use SDL. diff --git a/results/classifier/accel-gemma3:12b/vmm/2645 b/results/classifier/accel-gemma3:12b/vmm/2645 new file mode 100644 index 000000000..39e8896e2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2645 @@ -0,0 +1,24 @@ + +Failed shutdown during record with `ide-hd` disk. +Description of problem: +Running `shutdown -h now` on the guest with an `ide-hd` disk during a recording results in a long wait, followed by a BMDMA error. +Steps to reproduce: +1. Install Ubuntu Server guest OS and create disk snapshot +1. Reboot and log in: `qemu-system-x86_64 -hda ubuntu_snapshot.qcow2 -m 2g -net none -monitor stdio` +2. Take a snapshot: `savevm loggedin` +3. Start recording from VM snapshot: `./qemu/build/qemu-system-x86_64 -icount shift=auto,rr=record,rrfile=ubuntu_shutdown.bin -drive file=ubuntu_snapshot.qcow2,if=none,id=img-direct -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device ide-hd,drive=img-blkreplay -loadvm loggedin -net none -m 2g` +4. Run `shutdown -h now` in guest +5. Wait (~5-10 mins) +6. Observe BMDMA error (see below) +Additional information: +``` +ata1.00: exeption Emask 0x0 SAct 0.0 SErr 0.0 action 0x6 +ata1.00: BMDMA stat 0x5 +ata1.00: failed command: READ DMA +ata1.00: cmd c8/xx:xx:xx:xx:xx/xx:xx:xx:xx:xx/xx tag - dma 4096 in + res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) +ata1.00: revalidation failed (errno=-2) +... +``` + +Note: Running the same command on a guest with a `virtio` disk results in further progress, but still does not shut down (stuck on `[ OK ] Stopped Create final runtime dir for shutdown pivot root.`) diff --git a/results/classifier/accel-gemma3:12b/vmm/2646 b/results/classifier/accel-gemma3:12b/vmm/2646 new file mode 100644 index 000000000..7e2dedf2c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2646 @@ -0,0 +1,26 @@ + +osx 10.6.8 guest on x86-64 macos 10.12 host can't boot on HVF, boots on tcg +Description of problem: +for some reason HVF acceleration does not work with mac-on-mac. Haiku beta5 (x64), win10 x64, Debian netinstall 12.7.0 - all works. +Steps to reproduce: +``` +1. get 10.6.8 image from archive.org +2. bin/qemu-system-x86_64 -device isa-applesmc,osk="well_known_string" -usb -M pc-q35-2.11 -device usb-kbd -device usb-tablet -m 1536 -smp 1 -cpu Penryn,vendor=GenuineIntel,+ssse3,+sse4.1,+sse4.2 -L /opt/local/share/qemu -device ac97 -vnc :3 --no-reboot -accel hvf -boot c -bios usr/share/edk2-ovmf-x64/OVMF_CODE.fd -hda osx-10.6-xcode-compressed-efi.qcow2 -d unimp +audio: Could not create a backend for voice `ac97.pi' +audio: Could not create a backend for voice `ac97.mc' +audio: Could not create a backend for voice `ac97.pi' +audio: Could not create a backend for voice `ac97.mc' +ahci: IRQ#0 level:1 +ahci: IRQ#0 level:1 + +{many more of those} +``` +and at this point qemu quits. + +without --no-reboot it reboots + +tried both UEFI boot (using https://github.com/khronokernel/khronokernel.github.io/blob/master/Binaries/OpenCore/EFI-LEGACY.img.zip?raw=true , currently integrated into hdd image) and Clover-5160-X64.iso + +if I remove -accel hvf and replace it with accel tcg guest boots. + +i tried to capture moment when it reboots on video but I can't catch anything :( diff --git a/results/classifier/accel-gemma3:12b/vmm/2648 b/results/classifier/accel-gemma3:12b/vmm/2648 new file mode 100644 index 000000000..06a152b7c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2648 @@ -0,0 +1,12 @@ + +Possible dereference of NULL in block/qapi.c +Description of problem: +qdict_get can return NULL if the "data" key is not found in the obj dictionary. Then if NULL is passed to the qobject_is_empty_dump function, it will be dereferenced when calling the qobject_type function. + +https://github.com/qemu/qemu/blob/92ec7805190313c9e628f8fc4eb4f932c15247bd/block/qapi.c#L891-L892 + +I think that data check for NULL should be added. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/accel-gemma3:12b/vmm/2649 b/results/classifier/accel-gemma3:12b/vmm/2649 new file mode 100644 index 000000000..305f534c1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2649 @@ -0,0 +1,41 @@ + +Data corruption with qcow2 images +Steps to reproduce: +``` +# Create an example file with old version of qemu-img and fill it with random data. +$ qemu-img-8.2.2 create -f qcow2 file.qcow2 600000000000 +$ qemu-nbd-8.2.2 -c /dev/nbd0 file.qcow2 +$ dd if=/dev/random of=/dev/nbd0 bs=1000000 count=600000 +$ qemu-nbd-8.2.2 -d /dev/nbd0 +/dev/nbd0 disconnected + +# Get the correct checksum of both qcow2 file and its contents +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +$ qemu-nbd-8.2.2 -r -c /dev/nbd0 file.qcow2 +$ sha256sum -b /dev/nbd0 +5dac11e88f891740da3b655588b2e62037962d1ba6377efce30124d6224dd0d1 */dev/nbd0 +$ qemu-nbd-8.2.2 -d /dev/nbd0 +/dev/nbd0 disconnected + +# Use the qcow2 file with new version. +# We're using qemu-nbd here, but the same happens when qcow2 is attached to a guest +# running in the new version qemu-system-86_64-9.1.1 and can be seen through guest's +# /dev/vda. +# Note that the checksum is different than before, and also non-deterministic +# (running sha256sum twice produces different results even though the file is +# read-only and hasn't changed). +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +$ qemu-nbd-9.1.1 -r -c /dev/nbd0 file.qcow2 +$ sha256sum -b /dev/nbd0 +1793a38b9b964d3fc643629284722373e9d5dedea68e35900ace777b57688926 */dev/nbd0 +$ sha256sum -b /dev/nbd0 +98f900f9cd174493d0bfcf06e2bc86f5ee99dfa04c90d6832fa941e384b62d49 */dev/nbd0 +$ qemu-nbd-9.1.1 -d /dev/nbd0 +/dev/nbd0 disconnected +$ sha256sum -b file.qcow2 +ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2 +``` +Additional information: +No errors in either host or guest logs. When using a qcow2 with an actual filesystem, you may see reports of corruption from the filesystem driver. diff --git a/results/classifier/accel-gemma3:12b/vmm/2650 b/results/classifier/accel-gemma3:12b/vmm/2650 new file mode 100644 index 000000000..ff54fc10e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2650 @@ -0,0 +1,193 @@ + +qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed +Description of problem: +If a named dirty bitmap already exists on a disk and another disk is added via hotplug after the guest has booted, it will definitely cause the hot migration to fail. +Steps to reproduce: +1. Create 2 images of type qcow2 + + ``` + qemu-img create -f qcow2 vda.qcow2 50G + qemu-img create -f qcow2 vdb.qcow2 2G # set to 2G + ``` +2. Start the guest using the following libvirt xml + + ``` + # virsh create i-btacsctt.xml + + <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm"> + <name>i-btacsctt</name> + <uuid>973f7352-ad1d-31ea-9a9f-237f3e9a384f</uuid> + <memory unit="MiB">2048</memory> + <vcpu current="2">2</vcpu> + <os> + <type arch="x86_64" machine="pc">hvm</type> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <devices> + <emulator>/opt/qemu-5.1.0.9/usr/bin/qemu-system-x86_64</emulator> + <disk device="disk" type="file"> + <driver cache="writeback" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vda.qcow2"/> + <target dev="vda"/> + </disk> + <disk device="disk" type="file"> + <driver cache="none" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdb.qcow2"/> + <target dev="vdb"/> + </disk> + </devices> + </domain> + ``` +3. Create bitmap for vda + + ``` + # The node name of vda is "libvirt-2-format" + virsh qemu-monitor-command i-btacsctt --hmp "info block" + libvirt-2-format: /tmp/echohu3/vda.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk0/virtio-backend + Cache mode: writethrough + + libvirt-1-format: /tmp/echohu3/vdb.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk1/virtio-backend + Cache mode: writeback, direct + + # Create bitmap + virsh qemu-monitor-command i-btacsctt '{"execute":"block-dirty-bitmap-add","arguments":{"node":"libvirt-2-format","name":"bitmap0","persistent":true}}' + ``` +4. Create vdc and run hotpluggin + + ``` + qemu-img create -f qcow2 vdc.qcow2 50G + + cat disk.xml + <disk device="disk" type="file"> + <driver cache="none" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdc.qcow2"/> + <target dev="vdc"/> + </disk> + + virsh attach-device i-btacsctt disk.xml + ``` +5. Start live migrationg + + ``` + # scp *.qcow2 172.31.68.42:/tmp/echohu3/ + virsh qemu-monitor-command i-btacsctt --hmp "migrate_set_capability dirty-bitmaps on" + virsh dumpxml --migratable i-btacsctt >/tmp/ivm-btacsctt.xml + virsh migrate --live --abort-on-error --xml /tmp/ivm-btacsctt.xml i-btacsctt qemu+tcp://172.31.68.42/system + error: internal error: qemu unexpectedly closed the monitor: qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed. + ``` +Additional information: +Set breakpoints on the source side + +``` +gdb -p $pid -ex "break add_bitmaps_to_list" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 add_bitmaps_to_list (bs=bs@entry=0x55c5bbaf85d0, bs_name=0x55c5bbafc674 "libvirt-2-format", alias_map=alias_map@entry=0x0, s=<optimized out>) at migration/block-dirty-bitmap.c:502 +#1 0x000055c5ba3b2878 in init_dirty_bitmap_migration (s=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:660 +#2 dirty_bitmap_save_setup (f=0x55c5bc981c40, opaque=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:1226 +#3 0x000055c5ba3a3c4d in qemu_savevm_state_setup (f=0x55c5bc981c40) at migration/savevm.c:1176 +#4 0x000055c5ba39e16b in migration_thread (opaque=opaque@entry=0x55c5bbaa2400) at migration/migration.c:3487 +#5 0x000055c5ba530cf3 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007f39846d9609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007f3983d11293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +(gdb) p bs->node_name +$4 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p bitmap->name +$5 = 0x55c5bbaf13d0 "bitmap0" +``` + +Set a breakpoint on the target side after hitting the breakpoint on the source side. + +``` +gdb -p $pid -ex "break serialization_chunk if ((start + count - 1) >> hb->granularity) >= hb->size" -ex "break dirty_bitmap_load_header" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 dirty_bitmap_load_header (alias_map=0x0, s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:1146 +#1 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1187 +#2 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#3 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#4 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#5 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#6 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#7 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#8 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#9 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +``` + +in dirty_bitmap_load_header + +``` +s->bs = bdrv_lookup_bs(s->node_name, s->node_name, &local_err); // node_name is "libvirt-2-format" +s->bitmap = bdrv_find_dirty_bitmap(s->bs, s->bitmap_name); // bitmap_name is "bitmap0" + +# Target side: “libvirt-2-format” is the node name of vdb. +(gdb) p s->bs->node_name +$10 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p s->bs->filename +$11 = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times> +``` + +We can also see from the target /var/log/libvirt/qemu/i-btacsctt.log file that “libvirt-2-format” is the node name of the vdb，while the node name of vda is libvirt-3-format. + +``` +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vda.qcow2","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"discard":"ignore","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x2,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdb.qcow2","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdc.qcow2","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"ignore","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +``` + +From the source code, we know that HBitmap.size is from vdb size (2G), but bitmap is from vda (50G), so it triggers assert exception in serialization_chunk. + +``` +(gdb) bt +#0 serialization_chunk (hb=hb@entry=0x55748ba28470, start=2147483648, count=536870912, first_el=first_el@entry=0x7f53503ffd20, el_count=el_count@entry=0x7f53503ffd18) at util/hbitmap.c:610 +#1 0x0000557487f18654 in hbitmap_deserialize_zeroes (hb=0x55748ba28470, start=start@entry=2147483648, count=count@entry=536870912, finish=finish@entry=false) at util/hbitmap.c:701 +#2 0x0000557487e7cfb0 in bdrv_dirty_bitmap_deserialize_zeroes (bitmap=<optimized out>, offset=offset@entry=2147483648, bytes=bytes@entry=536870912, finish=finish@entry=false) at block/dirty-bitmap.c:749 +#3 0x0000557487d86b51 in dirty_bitmap_load_bits (s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:992 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +#5 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#6 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#7 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#8 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#9 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#10 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#11 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#12 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +#13 0x00007ffffb29c410 in () +#14 0x0000000000000000 in () +(gdb) p *hb +$16 = {orig_size = 2147483648, size = 32768, count = 0, granularity = 16, meta = 0x0, levels = {0x55748ad55ad0, 0x55748acd8df0, 0x55748b0866a0, 0x55748acf8c10, 0x55748b1c4180, 0x55748b154f60, 0x55748adf2370}, sizes = {1, 1, 1, 1, 1, 8, + 512}} +``` + +``` +(gdb) f 4 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +(gdb) p *s->bs +$21 = {open_flags = 10274, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x557488aa2ee0 <bdrv_qcow2>, opaque = 0x55748acf8c90, aio_context = 0x55748acd1080, + aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing_file = '\000' <repeats 4095 times>, auto_backing_file = '\000' <repeats 4095 times>, + backing_format = '\000' <repeats 15 times>, full_open_options = 0x55748b3c68e0, exact_filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing = 0x0, file = 0x55748aa5de40, bl = {request_alignment = 1, + max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0, + supported_zero_flags = 260, supported_truncate_flags = 2, node_name = "libvirt-2-format", '\000' <repeats 15 times>, node_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0e8}}, + bs_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0f8}}, monitor_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d108}}, refcnt = 2, + op_blockers = {{lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x55748aa5de40}, parents = {lh_first = 0x55748bbc0380}, options = 0x55748ad4d2d0, explicit_options = 0x55748ad525a0, + detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 4194304, before_write_notifiers = {notifiers = {lh_first = 0x0}}, write_threshold_offset = 0, write_threshold_notifier = {notify = 0x0, node = { + le_next = 0x0, le_prev = 0x0}}, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 39 times>, __align = 0}, initialized = true}, dirty_bitmaps = {lh_first = 0x55748b4655f0}, wr_highest_offset = {value = 0}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, io_plugged = 0, + enable_write_cache = 0, quiesce_counter = 0, recursive_quiesce_counter = 0, write_gen = 0, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0}, + tracked_requests = {lh_first = 0x0}, flush_queue = {entries = {sqh_first = 0x0, sqh_last = 0x55748ad52570}}, active_flush_req = false, flushed_gen = 0, never_freeze = false} +``` + +When we merge into commit https://gitlab.com/qemu-project/qemu/-/commit/31e4c354b38cd42a051ad030eb7779d5e7ee32fe and then run `block-bitmap-mapping` before migration, the hot migration can be completed successfully. I would like to confirm with the community whether this solution is reasonable and if there are any other solutions to address this issue. + +``` +virsh qemu-monitor-command i-btacsctt '{"execute": "migrate-set-parameters", "arguments":{"block-bitmap-mapping":[{"node-name":"libvirt-2-format", "alias":"libvirt-3-format","bitmaps":[{"name":"bitmap0", "alias":"bitmap0"}]}]}}' +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2665 b/results/classifier/accel-gemma3:12b/vmm/2665 new file mode 100644 index 000000000..e1525e1bf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2665 @@ -0,0 +1,12 @@ + +target/arm: cannot boot when CPU supports SME +Description of problem: +On macOS 15.2 beta, Apple's Hypervisor.framework exposes the SME feat flag to QEMU. As a result, in `arm_cpu_sme_finalize`, `cpu_isar_feature(aa64_sme, cpu)` returns true and the program will always exit with the following: + +``` +qemu-aarch64-softmmu: cannot disable sme4224 +All SME vector lengths are disabled. +With SME enabled, at least one vector length must be enabled. +``` + +This is because `vq_supported` and `vq_init` are both 0 as they are not initialized anywhere. It seems that in the original commit e74c097638d38b46d9c68f11565432034afc0ad0 the only place `cpu->sme_vq.supported` is initialized is with `aarch64_max_initfn` when KVM and HVF are not used as the backend. diff --git a/results/classifier/accel-gemma3:12b/vmm/2669 b/results/classifier/accel-gemma3:12b/vmm/2669 new file mode 100644 index 000000000..1957c7477 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2669 @@ -0,0 +1,19 @@ + +CPU Hotplug (Host Model) Causes the Windows VM to BSOD +Description of problem: +The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots. + +I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged). + +My goal is to be able to hotplug CPUs even when the host CPU supports SGX. + +I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck. +Steps to reproduce: +1. Create a simple Windows VM, +2. start the VM, +3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html). + +I can provide you the VM as well but its image (QCOW2) has around 10G in size. + +Best regards +Martin Dráb diff --git a/results/classifier/accel-gemma3:12b/vmm/2680 b/results/classifier/accel-gemma3:12b/vmm/2680 new file mode 100644 index 000000000..21241fce1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2680 @@ -0,0 +1,15 @@ + +GTK accelerators (including releasing input grab) don't work in keyboard layouts that utilize AltGr on Windows +Description of problem: +With a non-QWERTY (in my case, Colemak) layout active, it's not possible to ungrab input from the window using the Ctrl-Alt-G. The key combination is simply ignored, whether the G is typed using the physical key G on the keyboard or the one where it would be mapped by the keyboard layout (physical T key for Colemak). Thankfully, because of #2225, the mouse cursor isn't actually captured, which allows me to move the mouse outside the window and close QEMU from the taskbar instead. + +Temporarily switching back to a QWERTY layout before the grab happens allows input to be released using the key combo. However this needs to be done before the capture as otherwise QEMU will simply intercept any shortcuts to toggle the layout. + +I suspect there's some mismatch between the input grabbing code and the GTK UI, where one is using the keyboard scancode to determine when to forward the key, but the GTK UI then uses the mapped letter from the layout and fails to activate the shortcut. +Steps to reproduce: +1. Configure a non-QWERTY layout (such as Dvorak or Colemak) in the system settings +1. Launch QEMU (it's not necessary to load any guest, booting the BIOS is fine) +2. Click on the window which will automatically capture input +3. Try to release using the Ctrl-Shift-G shortcut (in either layout), which should be ignored +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2681 b/results/classifier/accel-gemma3:12b/vmm/2681 new file mode 100644 index 000000000..d8283764b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2681 @@ -0,0 +1,2 @@ + +QEMU build system should halt, if glib version is lower than needed diff --git a/results/classifier/accel-gemma3:12b/vmm/2703 b/results/classifier/accel-gemma3:12b/vmm/2703 new file mode 100644 index 000000000..8e28cf7b0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2703 @@ -0,0 +1,41 @@ + +ptimer period sporadically too long +Description of problem: +A ptimer in a custom device with a frequency of 10kHz is sporadically called after more than 100,000ns in virtual time have elapsed. + +With a icount shift of 4 or 5 this happens almost everytime before the linux guest can even finish booting. + +With a shift of 0 this happens very rarely, but it does occur from time to time. +Steps to reproduce: +1. setup a ptimer with a frequency of 10kHz and assert that the time passed between callbacks is exactly 100,000ns +2. run +3. wait for boom +Additional information: +``` +// Timer setup +ptimer_transaction_begin(state->timer); + +ptimer_set_freq(state->timer, 10000); +ptimer_run(state->timer, 0); + +ptimer_transaction_commit(state->timer); +``` +``` +// timer callback +int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); +static int64_t last = 0; +if (last > 0) +{ + if (now - last != 100000) + { + fprintf(stderr, "error tick %ld after %ld is incorrect: %ld\n", now, last, now - last); + assert(0); + } +} +last = now; +``` + +``` +error tick 47867503135 after 47867400000 is incorrect: 103135 +qemu-system-x86_64: ../...file.c:119: timer_callback: Assertion `0' failed. +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2705 b/results/classifier/accel-gemma3:12b/vmm/2705 new file mode 100644 index 000000000..5a0cf932e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2705 @@ -0,0 +1,18 @@ + +USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X) +Steps to reproduce: +1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above. +2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off` +3. Boot macOS. + +USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable. + + +While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection: + + * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.) + * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2. + * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped. + * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references. + +It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup. diff --git a/results/classifier/accel-gemma3:12b/vmm/2714 b/results/classifier/accel-gemma3:12b/vmm/2714 new file mode 100644 index 000000000..8d1cf46d6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2714 @@ -0,0 +1,8 @@ + +Potential memory leak in virtio-crytpto +Description of problem: +There is a potential memory leak while using virtio-crypto with vhost-user backend. + +The problem is due to misuse of error_setg in [backends/cryptodev-vhost-user.c#L284](https://gitlab.com/qemu-project/qemu/-/blob/master/backends/cryptodev-vhost-user.c#L284). After invoking error_setg(&local_error, ...), current procedure should not return without freeing err object pointed by local_error. + +The same problem occured in cryptodev-builtin, which has been discussed in #2283 and fixed in f6abce29cc4afa0445cb3b29a265a114ac9fa744. The same fixes should be applied to cryptodev-vhost-user. diff --git a/results/classifier/accel-gemma3:12b/vmm/2724 b/results/classifier/accel-gemma3:12b/vmm/2724 new file mode 100644 index 000000000..1ae5de4f7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2724 @@ -0,0 +1,9 @@ + +Invalid DRM modifier in ScanoutDMABUF call +Description of problem: +`modifier` parameter in `ScanoutDMABUF` callback is always `0xffffffffffffff` (`DRM_FORMAT_RESERVED`) +Steps to reproduce: +1. Run QEMU with D-Bus display +2. Connect D-Bus display client and print modifier +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2728 b/results/classifier/accel-gemma3:12b/vmm/2728 new file mode 100644 index 000000000..7d0d99acf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2728 @@ -0,0 +1,16 @@ + +QEMU/Virt-Manager + QXL 4k Resolution + Win 10 and Win 11 Guest freeze +Description of problem: +I use two 4k displays in my VM with 150% display scaling. After a random amount of time the screen locks up. It can lock up before i can log in or it can wait a few minutes into using it before it stops responding. It still pings but is unresponsive via the display. I've tried several different builds of the guest drivers but that did not work, the only solution has been to revert to QEMU v9.0.2-1. +Steps to reproduce: +1.Create new x86 VM using QXl video, Install Windows 10 or Windows 11 and latest guest drivers from spice and fedora +2.Open with virt viewer and resize both screens to 3840 x 2160 or use autosize +3.Set display scaling to 150% +4.Lockup occurs at some point after that but not more than 5 minutes. +Additional information: +There seems to be a similar bug here:https://gitlab.com/qemu-project/qemu/-/issues/1628#note_214460662 +also a debian forum post here: https://forums.debian.net/viewtopic.php?t=160631 +QEMU v9.0.2-1 does not have this problem, eliminating the guest drivers as a culprit + + +/label ~"kind::Bug" diff --git a/results/classifier/accel-gemma3:12b/vmm/2732 b/results/classifier/accel-gemma3:12b/vmm/2732 new file mode 100644 index 000000000..1e08947ff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2732 @@ -0,0 +1,40 @@ + +Segmentation fault with PCI GPU +Description of problem: +Upon attempting to launch the virtual machine, Qemu crashes with Segfault. The issue only occurs it's launched with a passthrough GPU with the vfio driver. It is an Nvidia RTX 3060 GPU. The VM boots fine without the GPU PCI device added. +Steps to reproduce: +1. Create a VM with the GPU PCI device added +2. Attempt to boot it +3. virt-manager will display: "libvirt.libvirtError: internal error: QEMU unexpectedly closed the monitor" +Additional information: +GDB backtrace: +``` +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +Downloading 116.51 K source file /usr/src/debug/qemu/build/../qemu-9.1.2/system/memory.c +memory_region_update_container_subregions () at ../qemu-9.1.2/system/memory.c:2616 +2616 QTAILQ_FOREACH(other, &mr->subregions, subregions_link) { +(gdb) bt +#0 memory_region_update_container_subregions () at ../qemu-9.1.2/system/memory.c:2616 +#1 memory_region_add_subregion_common () at ../qemu-9.1.2/system/memory.c:2640 +#2 0x0000555555ade66a in memory_region_add_subregion_overlap () at ../qemu-9.1.2/system/memory.c:2657 +#3 vfio_probe_nvidia_bar0_quirk () at ../qemu-9.1.2/hw/vfio/pci-quirks.c:966 +#4 vfio_bar_quirk_setup () at ../qemu-9.1.2/hw/vfio/pci-quirks.c:1259 +#5 0x0000555555ae8212 in vfio_realize () at ../qemu-9.1.2/hw/vfio/pci.c:3133 +#6 0x000055555586c3ab in pci_qdev_realize () at ../qemu-9.1.2/hw/pci/pci.c:2097 +#7 0x0000555555b924f3 in device_set_realized () at ../qemu-9.1.2/hw/core/qdev.c:510 +#8 0x0000555555b9c37f in property_set_bool () at ../qemu-9.1.2/qom/object.c:2354 +#9 0x0000555555b9a21a in object_property_set () at ../qemu-9.1.2/qom/object.c:1463 +#10 0x0000555555b9abbf in object_property_set_qobject () at ../qemu-9.1.2/qom/qom-qobject.c:28 +#11 object_property_set_bool () at ../qemu-9.1.2/qom/object.c:1533 +#12 0x000055555594dafb in qdev_device_add_from_qdict () at ../qemu-9.1.2/system/qdev-monitor.c:719 +#13 0x00005555559586f1 in qemu_create_cli_devices () at ../qemu-9.1.2/system/vl.c:2664 +#14 qmp_x_exit_preconfig () at ../qemu-9.1.2/system/vl.c:2721 +#15 0x0000555555962396 in qemu_init () at ../qemu-9.1.2/system/vl.c:3766 +#16 0x00005555556d2abd in main () at ../qemu-9.1.2/system/main.c:47 +``` + +dmesg: +``` +[ 4846.200960] qemu-system-x86[26518]: segfault at b8 ip 00006149e75a64e6 sp 00007fff4c85fbe0 error 4 in qemu-system-x86_64[5c24e6,6149e7155000+72c000] likely on CPU 4 (core 4, socket 0) +[ 4846.200968] Code: 2e 01 83 c0 01 89 05 0d cd 2e 01 48 8b 43 40 48 85 c0 74 16 ba 01 00 00 00 f0 0f c1 50 18 81 fa fe ff ff 7f 0f 87 c4 00 00 00 <49> 8b 84 24 b8 00 00 00 48 85 c0 74 55 8b 93 b0 00 00 00 eb 11 0f +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2739 b/results/classifier/accel-gemma3:12b/vmm/2739 new file mode 100644 index 000000000..554664e5b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2739 @@ -0,0 +1,4 @@ + +Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation +Additional information: +This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups. diff --git a/results/classifier/accel-gemma3:12b/vmm/2741 b/results/classifier/accel-gemma3:12b/vmm/2741 new file mode 100644 index 000000000..c8c7aeb0c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2741 @@ -0,0 +1,62 @@ + +qemu-system-ppc no longer boots NetBSD/macppc +Description of problem: +Since commit 7419dc5b2b5bcc929d91e8920692041a8f6d1977, qemu no longer boots NetBSD/macppc. +Steps to reproduce: +``` +wget https://www.gson.org/bugs/qemu/macppc-20241221/boot.iso.gz +wget https://www.gson.org/bugs/qemu/macppc-20241221/wd0.img.gz +gunzip boot.iso.gz +gunzip wd0.img.gz +qemu-system-ppc \ + -m 256 \ + -nographic \ + -drive file=wd0.img,format=raw,media=disk,snapshot=on \ + -drive file=boot.iso,format=raw,media=cdrom,readonly=on,index=2 \ + -prom-env boot-device=cd:,netbsd-GENERIC \ + -M mac99 \ + -prom-env qemu_boot_hack=y +``` + +At the "root device:" prompt, enter `wd0a` + +At the "dump device" prompt, just press enter + +At the "file system" prompt, just press enter + +At the "init path" prompt, just press enter + +Expected behavior: The guest system boots to a login prompt + +Observed behavior: qemu exits with the following error message: + +``` +qemu: fatal: Raised an exception without defined vector 94 + +NIP fdb5d440 LR fdb5dc20 CTR fd62a340 XER 20000000 CPU#0 +MSR 0200d032 HID0 809400a4 HF 02004012 iidx 0 didx 0 +TB 00000000 831919972 DECR 105840 +GPR00 0000000000000125 00000000ffffe8b0 00000000fde90008 0000000000000000 +GPR04 0000000000000000 00000000fdcfebac 00000000fdcfeb48 0000000000000001 +GPR08 0000000000000000 00000000fde90008 00000000ffffe8b0 00000000fdb5dc14 +GPR12 0000000044004482 0000000000000000 00000000fdee0efc 00000000fdef57f0 +GPR16 00000000fdef57c8 0000000000000000 00000000ffffea94 00000000ffffeac8 +GPR20 00000000fdee0f3c 0000000001800114 0000000000000000 0000000000000001 +GPR24 0000000000000000 00000000fdef57e0 0000000000000001 00000000fdb5da2c +GPR28 00000000ffffe9c0 00000000ffffe8f8 00000000fdcffb4c 00000000fdcfeb48 +CR 24004482 [ E G - - G G L E ] RES 004@ffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 00000000 + SRR0 fd62a360 SRR1 0200d032 PVR 000c0209 VRSAVE 00000000 +SPRG0 00c02bc0 SPRG1 44004482 SPRG2 fde90008 SPRG3 00000000 +SPRG4 00000000 SPRG5 00000000 SPRG6 00000000 SPRG7 00000000 + SDR1 00e0001f DAR cd538000 DSISR 42000000 +Aborted +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2745 b/results/classifier/accel-gemma3:12b/vmm/2745 new file mode 100644 index 000000000..7b48d5b86 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2745 @@ -0,0 +1,27 @@ + +Qemu should send RARP for vhostuser regardless of whether virtio supports GUEST_ANNOUNCE +Description of problem: +When virtio reports to qemu that GUEST_ANNOUNCE is supported, qemu will not send RARP. The assumption, I think, is that guest kernel will do whatever is needed to announce the guest. The problem with this assumption is that 1) kernel won't send RARPs; 2) for IPv4 and IPv6 it will send GARPs and NAs; 3) for interfaces with no IP addresses, I think it won't send anything at all. + +RARPs are useful because they allow to notify regardless of IP configuration. I've [asked](https://issues.redhat.com/browse/RHEL-71919]) RHEL kernel folks to consider issuing RARPs from the guest kernel, but it won't happen overnight, and regardless, it's not a complete solution since we cannot expect all guests running a patched kernel with such feature. + +RARP packets are also often expected by underlying network components. For example, OVN controller has a special "activation-strategy=rarp" configuration that makes OVN wait for a RARP from destination chassis on live migration, and only then unblock traffic for the port. Since RARP is not issed by Qemu nor virtio-net, the OVN port is never unblocked (until its configuration is reset by CMS). + +I think what should be done from Qemu side is to send RARP for vhostuser ports regardless of whether virtio supports GUEST_ANNOUNCE. I **think** this can be achieved by removing this code: + +``` + /* If guest supports GUEST_ANNOUNCE do nothing */ + if (virtio_has_feature(dev->acked_features, VIRTIO_NET_F_GUEST_ANNOUNCE)) { + return 0; + } +``` +Steps to reproduce: +1. Start a VM with vhostuser* port and fresh virtio guest driver. +2. Live migrate it. +3. Observe that RARP is not sent from the migrated port. GARP (or NA for IPv6) is sent instead. +Additional information: +Some external bugs that may be relevant: + +- RHEL kernel request to send RARPs from virtio: https://issues.redhat.com/browse/RHEL-71919 (won't fix the issue for older unpatched kernels) +- Request for OVN to handle GARPs and NAs: https://issues.redhat.com/browse/FDP-1042 (won't solve for unaddressed ports!) +- An attempt to work around the issue in OpenStack Neutron OVN env by disabling activation strategy: https://issues.redhat.com/browse/OSPRH-12571 (not a great long term solution) diff --git a/results/classifier/accel-gemma3:12b/vmm/2747 b/results/classifier/accel-gemma3:12b/vmm/2747 new file mode 100644 index 000000000..032972731 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2747 @@ -0,0 +1,10 @@ + +External snapshots are created world-readable when connecting via qemu+ssh://root +Description of problem: +External snapshots are created with world-readable permissions when connecting via `qemu+ssh://root`. +Steps to reproduce: +1. Create a VM over `qemu+ssh://root@$SERVER/system` +2. Create an external snapshot via virt-manager or with `virsh snapshot-create-as --domain testvm --name test --disk-only --diskspec vda,file=/var/lib/libvirt/images/test.qcow2 --atomic` +3. `ls -l /var/lib/libvirt/images/test.qcow2` +Additional information: +Issue doesn't seem to go away by adding `umask 077` in `$HOME/.profile` diff --git a/results/classifier/accel-gemma3:12b/vmm/2749 b/results/classifier/accel-gemma3:12b/vmm/2749 new file mode 100644 index 000000000..78f1069bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2749 @@ -0,0 +1,80 @@ + +TSAN/RaceHunter data race on bh->flags in aio_compute_bh_timeout +Description of problem: +Switching the TSAN build for `test-aio-multithread` unit test reveals the data race on `bh->flags` in `aio_compute_bh_timeout`. + +The same data race can be found in the list of warnings in #851 and #1496. + +I investigated the data race and I can reproduce the same race with our tool RaceHunter on the test `tests/unit/test-thread-pool.c` where two accesses may happen simultaneously. It is not false alarm, because RaceHunter introduces the delay and catches both accesses exactly at the same time, not just predicting the race due to missing happens-before as TSAN does. + +``` +WARNING: SMC RaceHunter: Data race found: + read access from thread 0 [handle=0] at pc=0x55b851f660b9, addr=7b1000000168 (4 bytes) + #0 aio_compute_bh_timeout util/async.c:259:18 + #1 aio_compute_timeout util/async.c:282:15 + #2 aio_poll util/aio-posix.c:628:26 (test-thread-pool+0xa4223f) + #3 test_submit_aio tests/unit/test-thread-pool.c:70:9 + #4 main tests/unit/test-thread-pool.c + + Previous atomic write access from thread 4 [handle=4] at pc=0x55b851f65e24, addr=7b1000000168 (4 bytes) + #0 aio_bh_enqueue util/async.c:81:17 + #1 qemu_bh_schedule util/async.c:235:5 + #2 worker_thread util/thread-pool.c:118:9 + #3 qemu_thread_start util/qemu-thread-posix.c:543:9 +``` + +Both are accesses to `flags` in `BHList` (`bh->flags`) +The write access in `aio_bh_enqueue` is protected by atomic operation `qatomic_fetch_or` while second read access is not atomic and not protected by locks. + +The read access in `aio_compute_bh_timeout` seems to rely on RCU mechanism `QSLIST_FOREACH_RCU(bh, head, next)`, but in this case the writer should also use RCU protected assign. +Steps to reproduce: +1. configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +2. make check-unit test-aio-multithread +3. See the warning in the log +``` +WARNING: ThreadSanitizer: data race (pid=3514443) + Atomic write of size 4 at 0x7b1000000168 by thread T17: + #0 aio_bh_enqueue /home/mordan/qemu/build/../util/async.c:81:17 (test-thread-pool+0xa5e933) + #1 qemu_bh_schedule /home/mordan/qemu/build/../util/async.c:235:5 (test-thread-pool+0xa5e933) + #2 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:118:9 (test-thread-pool+0xa66153) + #3 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0) + + Previous read of size 4 at 0x7b1000000168 by main thread: + #0 aio_compute_bh_timeout /home/mordan/qemu/build/../util/async.c:259:18 (test-thread-pool+0xa5ebc8) + #1 aio_compute_timeout /home/mordan/qemu/build/../util/async.c:282:15 (test-thread-pool+0xa5ebc8) + #2 aio_poll /home/mordan/qemu/build/../util/aio-posix.c:628:26 (test-thread-pool+0xa42d4f) + #3 do_test_cancel /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:199:9 (test-thread-pool+0x50f0e8) + #4 test_cancel_async /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:230:5 (test-thread-pool+0x50ec01) + #5 <null> <null> (libglib-2.0.so.0+0x7daed) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #6 __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 (libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e) + + As if synchronized via sleep: + #0 nanosleep out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:365:3 (test-thread-pool+0x34507d) + #1 g_usleep <null> (libglib-2.0.so.0+0x7ff76) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #2 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:111:15 (test-thread-pool+0xa66115) + #3 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0) + + Location is heap block of size 56 at 0x7b1000000140 allocated by main thread: + #0 malloc out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:667:5 (test-thread-pool+0x346151) + #1 g_malloc <null> (libglib-2.0.so.0+0x5e738) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #2 thread_pool_init_one /home/mordan/qemu/build/../util/thread-pool.c:333:27 (test-thread-pool+0xa655c8) + #3 thread_pool_new /home/mordan/qemu/build/../util/thread-pool.c:348:5 (test-thread-pool+0xa655c8) + #4 aio_get_thread_pool /home/mordan/qemu/build/../util/async.c:441:28 (test-thread-pool+0xa5ed54) + #5 thread_pool_submit_aio /home/mordan/qemu/build/../util/thread-pool.c:246:24 (test-thread-pool+0xa64f0d) + #6 thread_pool_submit /home/mordan/qemu/build/../util/thread-pool.c:295:5 (test-thread-pool+0xa65362) + #7 test_submit /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:49:5 (test-thread-pool+0x50e53f) + #8 <null> <null> (libglib-2.0.so.0+0x7daed) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #9 __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 (libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e) + + Thread T17 'worker' (tid=3514461, running) created by thread T16 at: + #0 pthread_create out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1022:3 (test-thread-pool+0x34793d) + #1 qemu_thread_create /home/mordan/qemu/build/../util/qemu-thread-posix.c:583:11 (test-thread-pool+0xa49550) + #2 do_spawn_thread /home/mordan/qemu/build/../util/thread-pool.c:146:5 (test-thread-pool+0xa65f5e) + #3 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:83:5 (test-thread-pool+0xa65f5e) + #4 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0) + +SUMMARY: ThreadSanitizer: data race /home/mordan/qemu/build/../util/async.c:81:17 in aio_bh_enqueue +``` + + +@hreitz, @kmwolf, @bonzini Are there any other synchronization that was intended to ensure that the accesses do not happen simultaneously? diff --git a/results/classifier/accel-gemma3:12b/vmm/2751 b/results/classifier/accel-gemma3:12b/vmm/2751 new file mode 100644 index 000000000..8812b65f8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2751 @@ -0,0 +1,2 @@ + +QEMU user emulation gdbstub emits incorrect file descriptor and errno values diff --git a/results/classifier/accel-gemma3:12b/vmm/2753 b/results/classifier/accel-gemma3:12b/vmm/2753 new file mode 100644 index 000000000..c4ee1bf2e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2753 @@ -0,0 +1,125 @@ + +Uninitialized read in vhost_user_backend_init. +Description of problem: +In backends/cryptodev-vhost.c::cryptodev_vhost_init, crypto->dev.config_ops is not initialized (See code below). I think here `g_new0` should be used instead of `g_new`. +``` +struct CryptoDevBackendVhost * +cryptodev_vhost_init( + CryptoDevBackendVhostOptions *options) +{ + ... + crypto = g_new(CryptoDevBackendVhost, 1); + crypto->dev.max_queues = 1; + crypto->dev.nvqs = 1; + crypto->dev.vqs = crypto->vqs; + + crypto->cc = options->cc; + + crypto->dev.protocol_features = 0; + crypto->backend = -1; + ... +} +``` +In vhost_user_backend_init, crypto->dev.config_ops will be dereferenced. Since it is uninitialized with 0, it is possible that a random value pointer will be dereferenced. +``` +static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque, + Error **errp) +{ + ... + if (virtio_has_feature(features, VHOST_USER_F_PROTOCOL_FEATURES)) { + bool supports_f_config = vus->supports_config || + (dev->config_ops && dev->config_ops->vhost_dev_config_notifier); + uint64_t protocol_features; + ... +``` + + +As a result, ASAN will capture this uninitialized, since it assigns 0xbe to every bytes of allocated but uninitilized memory. +Steps to reproduce: +1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html) +``` +wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz +meson setup -Dexamples=all build +cd build +ninja +meson install +cd examples +sudo ./dpdk-vhost_crypto --vdev 'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock +``` +After setting up the backend, should see something like: +``` +EAL: Detected CPU lcores: 48 +EAL: Detected NUMA nodes: 2 +EAL: Detected static linkage of DPDK +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: Selected IOVA mode 'PA' +EAL: VFIO support initialized +CRYPTODEV: Creating cryptodev crypto_aesni_mb0 +CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8 +IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0 +USER1: Processing on Core 7 started +VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode +VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213 +VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded +``` + +2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto) + +3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root. + +4.Run the command below to reproduce problem. +``` +cat << EOF | \ +./qemu-system-x86_64 --enable-kvm -m 512M \ +-object \ +memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \ +-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \ +socket,id=chardev0,path=/tmp/my-crypto.sock -object \ +cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \ +virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \ +stdio +EOF +``` +Additional information: +Here is the information reported by ASAN: +``` +==2270320==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000000] OPENED +../hw/virtio/vhost-user.c:2183:50: runtime error: member access within misaligned address 0xbebebebebebebebe for type 'const VhostDevConfigOps' (aka 'const struct VhostDevConfigOps'), which requires 8 byte alignment +0xbebebebebebebebe: note: pointer points here +<memory cannot be printed> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/virtio/vhost-user.c:2183:50 in +../hw/virtio/vhost-user.c:2183:50: runtime error: load of misaligned address 0xbebebebebebebebe for type 'int (*const)(struct vhost_dev *)', which requires 8 byte alignment +0xbebebebebebebebe: note: pointer points here +<memory cannot be printed> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/virtio/vhost-user.c:2183:50 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==2270320==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x5619d01bd606 bp 0x7fffc6d3add0 sp 0x7fffc6d3a4e0 T0) +==2270320==The signal is caused by a READ memory access. +==2270320==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used. + #0 0x5619d01bd606 in vhost_user_backend_init /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:2183:50 + #1 0x5619ced13a08 in vhost_dev_init /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1523:9 + #2 0x5619cef8cc30 in cryptodev_vhost_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:69:9 + #3 0x5619cef9aca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30 + #4 0x5619cef9a599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13 + #5 0x5619d0e22ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5 + #6 0x5619d0e18465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5 + #7 0x5619d0de5d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13 + #8 0x5619d0de5674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5 + #9 0x5619cef98960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5 + #10 0x5619cef71e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9 + #11 0x5619d067dc40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9 + #12 0x5619d067e6a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10 + #13 0x5619d067ec74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11 + #14 0x5619cef5582b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13 + #15 0x5619cef5253c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5 + #16 0x5619cef46efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5 + #17 0x5619d0e46f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5 + #18 0x7efeef09a082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 + #19 0x5619cd0be89d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:2183:50 in vhost_user_backend_init +==2270320==ABORTING +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2764 b/results/classifier/accel-gemma3:12b/vmm/2764 new file mode 100644 index 000000000..da5e3fd5e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2764 @@ -0,0 +1,48 @@ + +W32 Docker build fails +Description of problem: +Docker build fails: + +``` +make docker-test-mingw@fedora-win64-cross V=1 J=4 +``` + +with the following error: + +``` +Initialized empty Git repository in /tmp/qemu-test/src/subprojects/dtc/.git/ +fatal: unable to access 'https://gitlab.com/qemu-project/dtc.git/': Could not resolve host: gitlab.com + +../meson.build:2090:16: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', 'b6910bec11614980a21e46fbccc35934b671bd81'] +``` +Steps to reproduce: +1. `make docker-test-mingw@fedora-win64-cross V=1 J=4 DEBUG=1` +2. `cd $QEMU_SRC` +3. `mkdir build` +4. `cd build` +5. `../configure --cross-prefix=x86_64-w64-mingw32-` +Additional information: +The problem can be worked around by changing the line + +``` +subprojects="keycodemapdb libvfio-user berkeley-softfloat-3 berkeley-testfloat-3" +``` + +to + +``` +subprojects="keycodemapdb libvfio-user berkeley-softfloat-3 berkeley-testfloat-3 dtc" +``` + +in `archive-source.sh`. + +Additionally, https://wiki.qemu.org/Hosts/W32#Docker_based_cross_builds is outdated. +``` +make docker-test-mingw@fedora V=1 DEBUG=1 J=4 +``` +should be +``` +make docker-test-mingw@fedora-win64-cross V=1 DEBUG=1 J=4 +``` + +Additionally, i would suggest to create and enter build directory before calling configure and also add the make commands as shown in the "Steps to reproduce" section of this ticket. diff --git a/results/classifier/accel-gemma3:12b/vmm/277 b/results/classifier/accel-gemma3:12b/vmm/277 new file mode 100644 index 000000000..5c4f5f0a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/277 @@ -0,0 +1,2 @@ + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 diff --git a/results/classifier/accel-gemma3:12b/vmm/2772 b/results/classifier/accel-gemma3:12b/vmm/2772 new file mode 100644 index 000000000..9689139bf --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2772 @@ -0,0 +1,75 @@ + +qemu-img map command omits `offset` key in output for encrypted qcow2 files +Description of problem: +We use the `qemu-img map` command to retrieve metadata information from a qcow2 image. It functions as expected for non-encrypted qcow2 images. However, when the same command is executed on an encrypted qcow2 image, the output omits the `offset` key, which is critical for subsequent processing in our workflow. +Steps to reproduce: +1. Run qemu-img map on the encrypted incremental qcow2: +Command: + +``` + qemu-img map --object secret,id=sec0,data=trilio --output json -U --image-opts driver=qcow2,file.filename=incremental.qcow2,encrypt.format=luks,encrypt.key-secret=sec0 +``` +**Observed Output:** The command executes but does not include the offset key in the JSON output. +For example: +``` +[{ "start": 32191217664, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32191283200, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32193314816, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32193380352, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32195411968, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32195477504, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32197509120, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32197574656, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32199606272, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32199671808, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32201703424, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32201768960, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32203800576, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32203866112, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32205897728, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32205963264, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32207994880, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32208060416, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32210092032, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}, +{ "start": 32210157568, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false}, +{ "start": 32212189184, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}] +``` + +2. Decrypt the same encrypted incremental qcow2 image and re-run the qemu-img map command: +**Decryption command:** +``` +qemu-img convert -t writeback --object secret,id=sec0,data=trilio -O qcow2 --image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=incremental.qcow2 decrypt.qcow2 +``` +3. Run qemu-img map on the decrypted image: +**Command:** +``` +qemu-img map --output json -U decrypt.qcow2 +``` +Here, we don't need to pass the encryption key as we have already decrypted the qcow2. + +**Observed Output:** The JSON output includes the offset key as expected. Example: +``` +[{ "start": 0, "length": 106954752, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 106954752, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 327680}, +{ "start": 109051904, "length": 786432000, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 895483904, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 2490368}, +{ "start": 897581056, "length": 1866924032, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 2764505088, "length": 1638400, "depth": 0, "present": true, "zero": false, "data": true, "offset": 4653056}, +{ "start": 2766143488, "length": 402587648, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 3168731136, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 6291456}, +{ "start": 3170893824, "length": 140443648, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 3311337472, "length": 54394880, "depth": 0, "present": true, "zero": false, "data": true, "offset": 8519680}, +{ "start": 3365732352, "length": 2056388608, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5422120960, "length": 1114112, "depth": 0, "present": true, "zero": false, "data": true, "offset": 62980096}, +{ "start": 5423235072, "length": 4128768, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5427363840, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 64094208}, +{ "start": 5429526528, "length": 469696512, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5899223040, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 66256896}, +{ "start": 5901385728, "length": 90112000, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 5991497728, "length": 1638400, "depth": 0, "present": true, "zero": false, "data": true, "offset": 68485120}, +{ "start": 5993136128, "length": 2086600704, "depth": 0, "present": false, "zero": true, "data": false}, +{ "start": 8079736832, "length": 2686976, "depth": 0, "present": true, "zero": false, "data": true, "offset": 70189056}, +{ "start": 8082423808, "length": 24129830912, "depth": 0, "present": false, "zero": true, "data": false}] +``` + +The missing `offset` key in the output of the `qemu-img map` command for encrypted qcow2 images disrupts downstream processes that rely on this metadata. diff --git a/results/classifier/accel-gemma3:12b/vmm/2800 b/results/classifier/accel-gemma3:12b/vmm/2800 new file mode 100644 index 000000000..b8287fb5c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2800 @@ -0,0 +1,8 @@ + +-accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334) +Description of problem: +QEMU fails to use -accel i.e., qemu-system-aarch64-unsigned: -accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334) +Steps to reproduce: +1. Execute the above QEMU command line on a macOS Sequia 15.3 +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2805 b/results/classifier/accel-gemma3:12b/vmm/2805 new file mode 100644 index 000000000..4d15b9aa9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2805 @@ -0,0 +1,23 @@ + +vhost-device-snd does not report correctly the device conf size +Description of problem: +The vhost-user-snd frontend is incorrectly reporting the size of the device configuration space, which should be based on the features exposed by the device. For example, the `controls` field in the `virtio_snd_config` structure is optional and should only be included in the configuration size if the `VIRTIO_SND_F_CTLS` feature has been negotiated. + +This issue became apparent after commit `ab0c7fb2`, where `virtio_snd_config` was updated to include the `controls` field. The vhost-user-snd frontend, relying on this structure, started expecting `sizeof(virtio_snd_config)` when communicating with the backend, regardless of whether the `VIRTIO_SND_F_CTLS` feature was negotiated. As a result, any backend reporting a smaller configuration size—for example, one that does not support controls—cannot communicate with the frontend. We observed this problem in the vhost-device-sound rust-vmm device, which we partially fixed [here](https://github.com/rust-vmm/vhost-device/commit/8e7b7109316e1027548bc91cfcbb4b096b032c24). + +This behavior is incorrect because the configuration size should depend on the negotiated features. + +I am currently working on patch to fix this. +Steps to reproduce: +1. Run vhost-device-sound +```bash + cargo run --bin vhost-device-sound -- --socket=/tmp/vhost-sound.socket --backend=pipewire +``` +2. Run QEMU with the parameters above +3. In the guest run: +```bash +root@syzkaller:~# aplay /usr/share/sounds/alsa/Front_Left.wav +aplay: main:830: audio open error: No such file or directory +``` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2813 b/results/classifier/accel-gemma3:12b/vmm/2813 new file mode 100644 index 000000000..b58c446bd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2813 @@ -0,0 +1,10 @@ + +Cannot emulate Windows 95 / 98 +Description of problem: +If install Windows 95 / 98 on that configuration, Windows 95 / 98 crashed on "While initializing device NDIS: Windows protection error." message, or QEMU crashed. With this command line Windows 95 / 98 can worked on previous QEMU 7.<br>And please don't allow IME input on CJK (Chinese / Japanese / Korean) host system (that relied IME to input some text). Such input process is done by the IME in CJK operating system guest. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2818 b/results/classifier/accel-gemma3:12b/vmm/2818 new file mode 100644 index 000000000..5a40b72f6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2818 @@ -0,0 +1,8 @@ + +Passing `-M microvm` and `-smbios type=11...` results in smbios args being silently dropped +Description of problem: +(reporting as requested by `danpb` on IRC) + +Using the `-machine microvm` flag with the `smbios type=11...` argument results in the smbios options being silently discarded, because the microvm target doesn't seem to support the smbios feature. + +danpb on IRC suggested that passing those two incompatible flags should result in an error. diff --git a/results/classifier/accel-gemma3:12b/vmm/2822 b/results/classifier/accel-gemma3:12b/vmm/2822 new file mode 100644 index 000000000..8741fa56d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2822 @@ -0,0 +1,12 @@ + +Data race with state field of ThreadPoolElement +Description of problem: +A data race in the access of `ThreadPoolElement` state field in `util/thread-pool.c` was identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-thread-pool +MALLOC_PERTURB_=111 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-thread-pool --tap -k +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2829 b/results/classifier/accel-gemma3:12b/vmm/2829 new file mode 100644 index 000000000..2d35f1ed2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2829 @@ -0,0 +1,22 @@ + +SMB sharing on FIPS enabled hosts with Samba broken +Description of problem: +Similar to #2593 , newer security features on GNU+Linux host OSes are continuing +to break communication with guests running older OSes. + +QEMU executes the `smbd` process in [slirp.c](net/slirp.c) to facilitate the SMB +sharing between guest and host. + +The host `smbd` process links in GnuTLS for authentication ciphers and algorithm +primitives. When `smbd` processes SMB requests from these older OS's SMB implementations, +it errors out with error lines: + +`Failed to setup SPNEGO negTokenInit request` + +`Failed to start SPNEGO handler for negprot OID list!` +Steps to reproduce: +1. Access a GNU+Linux machine with GnuTLS library in FIPS mode which `smbd` links against +2. Run `qemu-system-*` with an older guest OS with a `smb` share to host +3. See errors in `/tmp/qemu.smb*/log.smbd` +Additional information: +# diff --git a/results/classifier/accel-gemma3:12b/vmm/2838 b/results/classifier/accel-gemma3:12b/vmm/2838 new file mode 100644 index 000000000..5f5ed41c4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2838 @@ -0,0 +1,9 @@ + +searchindex.js in HTML doc is not reproducible +Description of problem: +Builds should be reproducible, at least when `SOURCE_DATE_EPOCH` set to some value (see: <https://reproducible-builds.org/docs/source-date-epoch/>), but the QEMU HTML doc contains a file which isn't reproducible. +Steps to reproduce: +1. `guix build --no-grafts qemu && guix build --no-grafts --check --keep-failed qemu` +2. `diffoscope /gnu/store/3kym1ykv9r8n0hgbihqllch9ph136zx1-qemu-8.2.2-doc{,-check}` +Additional information: +[diffoscope-log.txt](/uploads/ab19f184082f343635df4fa7ef26b12e/diffoscope-log.txt) diff --git a/results/classifier/accel-gemma3:12b/vmm/284 b/results/classifier/accel-gemma3:12b/vmm/284 new file mode 100644 index 000000000..46d584f67 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/284 @@ -0,0 +1,2 @@ + +Assertion failed: (buf_len != 0), function soread, file socket.c, line 183. diff --git a/results/classifier/accel-gemma3:12b/vmm/2840 b/results/classifier/accel-gemma3:12b/vmm/2840 new file mode 100644 index 000000000..ed83c6068 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2840 @@ -0,0 +1,22 @@ + +After converting the Windows 10 system disk from qcow2 to LUKS format with pre-allocated space, the system fails to boot +Description of problem: +When converting a qcow2 file containing an installed Windows 10 system to LUKS format, using the --target-is-zero parameter in the conversion command prevents the LUKS image from shrinking. However, when attempting to boot the virtual machine with the converted LUKS file, VNC login shows a black screen, and the system fails to start. If the conversion is performed without the --target-is-zero parameter, the system boots up normally +Steps to reproduce: +1. create a luks image +qemu-img create -f qcow2 --object secret,data=123,id=sec0 -o preallocation=full,encrypt.format=luks,encrypt.key-secret=sec0 encry_ok.qcow2 50G +2. +qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2 -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2 --target-is-zero + +windows10.qcow2 container windows20 system and it can be booted +3. +./qemu-system-x86_64 -accel kvm -cpu SandyBridge -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -smp 4 -object secret,id=sec0,data=123,format=raw -drive if=none,driver=qcow2,file.filename=/sdc1/luzhipeng/encry_ok.qcow2,encrypt.key-secret=sec0,id=drive0,cache=none -device virtio-blk,drive=drive0,bootindex=1 -monitor stdio -vnc :4 + +4. vnc shows a black screen, and the system fails to start + +5. if use convert command: +qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2 -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2 + +6. the windows10 system can start successful +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2841 b/results/classifier/accel-gemma3:12b/vmm/2841 new file mode 100644 index 000000000..a4caa8e76 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/2843 b/results/classifier/accel-gemma3:12b/vmm/2843 new file mode 100644 index 000000000..34530f0a4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2843 @@ -0,0 +1,34 @@ + +Strange stdin/out <-> console issue (paste problem) . May be char-win-stdio.c bug. +Description of problem: +I was trying to execute QEMU with VM from command line(shell) and work inside a VM within that initial console. All goes well except... pasting from clipboard. Pastings from clipboard are truncated to somewhat less (no more) then a terminal width (in columns). + +I understand that it seems to be far from QEMU but I tried different terminals/shells/guest systems with the same result. The only things remain the same - QEMU. +Steps to reproduce: +In Windows open a console (shell). Run QEMU with guest serial attached to QEMU stdio. Try to paste some text. Pasted text will be truncated to 15-35 characters. Before QEMU run and after QEMU exit text pasted normally. +Additional information: +- Shell probed: **cmd**, **powershell** +- Terminals probed: **Windows Terminal**, **Alacritty**, **Wezterm**, **Windows Terminal Preview** +- Guest probed: **Alpine Linux**, **FreeBSD** +- Setting inside guest probed: various terminal speed/options via **stty** +- QEMU arguments probed: from **-nographics** to manually define **-chardev/-serial** with/without **-mon**. + +Finally I gave up. But want to mention that there are may be bug in source. When I tried to study source to find a hint for my issue I found that (char-win-stdio.c, line 162): +``` +is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0; + stdio->dwOldMode = dwMode; + + if (is_console) { +``` + +Documentation of **GetConsoleMode** function says: +``` +Return value: + +If the function succeeds, the return value is nonzero. +If the function fails, the return value is zero. +``` + +If understand correctly **is_console** will always be _true_. It will be _false_ only in case of invalid **stdio->hStdIn**. + +I don't how this is related to my issue just put here all info I have in hope of resolving. diff --git a/results/classifier/accel-gemma3:12b/vmm/2845 b/results/classifier/accel-gemma3:12b/vmm/2845 new file mode 100644 index 000000000..d3a69f831 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2845 @@ -0,0 +1,33 @@ + +memory leak in virtio-pci devices +Description of problem: +The Use-After-Free bug mentioned by #2440 **has not been solved**, but the same crash is not reproducable in the later versions. After reviewing the code, I found an initiailized address space `proxy->modern_cfg_mem_as` introduced by [`55fa4be`](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html "Inspect Commit Details") in `virtio_pci@hw/virtio/virtio-pci.c` will not be destroyed if the later realization is failed. +This will cause memory leak of the device object, which has unused reference and will not be destroyed. + +Relative Code in `virtio_pci_realize@virtio-pci.c`: + +```c +/* subclasses can enforce modern, so do this unconditionally */ +memory_region_init(&proxy->modern_bar, OBJECT(proxy), "virtio-pci", + /* PCI BAR regions must be powers of 2 */ + pow2ceil(proxy->notify.offset + proxy->notify.size)); + +address_space_init(&proxy->modern_cfg_mem_as, &proxy->modern_bar, + "virtio-pci-cfg-mem-as"); + +if (proxy->disable_legacy == ON_OFF_AUTO_AUTO) { + proxy->disable_legacy = pcie_port ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF; +} +``` +Steps to reproduce: +```bash +cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0 +device_add virtio-net,failover=on,bus=br1,id=dev0 +quit +EOF +``` + +**This will cause UAF report in version `9.0.2`, but will not in `9.2.0`,** despite the bug still existing in code. +Additional information: +For ASAN report, please refer to #2440. diff --git a/results/classifier/accel-gemma3:12b/vmm/2848 b/results/classifier/accel-gemma3:12b/vmm/2848 new file mode 100644 index 000000000..33a447837 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2848 @@ -0,0 +1,14 @@ + +i386 max_cpus off by one +Description of problem: +X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`). +The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. + +**Can we increase the limit to 256 vCPUs?** +I think so. + +Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. +According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. +APIC seems to be no hindrance to increase max_cpus to 256. + +**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently. diff --git a/results/classifier/accel-gemma3:12b/vmm/285 b/results/classifier/accel-gemma3:12b/vmm/285 new file mode 100644 index 000000000..1792c1efd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/285 @@ -0,0 +1,2 @@ + +qemu-user child process hangs when forking due to glib allocation diff --git a/results/classifier/accel-gemma3:12b/vmm/2852 b/results/classifier/accel-gemma3:12b/vmm/2852 new file mode 100644 index 000000000..37ffd9896 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2852 @@ -0,0 +1,81 @@ + +heap-use-after-free in timer_pending() +Description of problem: +In the QED block driver, the need_check_timer timer is freed in +bdrv_qed_detach_aio_context, but the pointer to the timer is not +set to NULL. This can lead to a use-after-free scenario +in bdrv_qed_drain_begin(). +Steps to reproduce: +1. [test.qed](/uploads/c8820345bfcd562308da99d9f83df3cf/test.qed) +2. ./qemu-img snapshot -q -a test test.qed +Additional information: +<details> +<pre> +./qemu-img snapshot -q -a test test.qed +==21083==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==21083==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400004ca50 at pc 0x56050d1462b6 bp 0x7fff14d0d870 sp 0x7fff14d0d868 +READ of size 8 at 0x60400004ca50 thread T0 + #0 0x56050d1462b5 in timer_pending /home/gerben/qemu-img_fuzz/build/../util/qemu-timer.c:483:16 + #1 0x56050cddf82e in bdrv_qed_drain_begin /home/gerben/qemu-img_fuzz/build/../block/qed.c:378:32 + #2 0x56050cb9bb65 in bdrv_do_drained_begin /home/gerben/qemu-img_fuzz/build/../block/io.c:364:13 + #3 0x56050cb9ca03 in bdrv_drain_all_begin_nopoll /home/gerben/qemu-img_fuzz/build/../block/io.c:506:9 + #4 0x56050cb96318 in bdrv_graph_wrlock /home/gerben/qemu-img_fuzz/build/../block/graph-lock.c:116:5 + #5 0x56050cd0cbc4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:294:9 + #6 0x56050cf95dd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #7 0x7f4adeddbefc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #8 0x56050c96a9f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +0x60400004ca50 is located 0 bytes inside of 48-byte region [0x60400004ca50,0x60400004ca80) +freed by thread T0 here: + #0 0x56050ca0daef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 + #1 0x56050cde6b86 in bdrv_qed_do_close /home/gerben/qemu-img_fuzz/build/../block/qed.c:619:5 + #2 0x56050cddbe85 in bdrv_qed_close /home/gerben/qemu-img_fuzz/build/../block/qed.c:639:5 + #3 0x56050cd0cbb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13 + #4 0x56050cf95dd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #5 0x7f4adeddbefc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +previously allocated by thread T0 here: + #0 0x56050ca0dfa7 in calloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3 + #1 0x7f4adf359670 in g_malloc0 (/lib64/libglib-2.0.so.0+0x5c670) + #2 0x56050cde4bd0 in bdrv_qed_do_open /home/gerben/qemu-img_fuzz/build/../block/qed.c:543:5 + #3 0x56050cde21a2 in bdrv_qed_open_entry /home/gerben/qemu-img_fuzz/build/../block/qed.c:569:16 + #4 0x56050d137706 in coroutine_trampoline /home/gerben/qemu-img_fuzz/build/../util/coroutine-ucontext.c:175:9 + #5 0x7f4adee066cf (/lib64/libc.so.6+0x526cf) + +SUMMARY: AddressSanitizer: heap-use-after-free /home/gerben/qemu-img_fuzz/build/../util/qemu-timer.c:483:16 in timer_pending +Shadow bytes around the buggy address: + 0x0c08800018f0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa + 0x0c0880001900: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa + 0x0c0880001910: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa + 0x0c0880001920: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd + 0x0c0880001930: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00 00 fa +=>0x0c0880001940: fa fa 00 00 00 00 00 fa fa fa[fd]fd fd fd fd fd + 0x0c0880001950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c0880001990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==21083==ABORTING +</pre> +</details> diff --git a/results/classifier/accel-gemma3:12b/vmm/2853 b/results/classifier/accel-gemma3:12b/vmm/2853 new file mode 100644 index 000000000..b3ef55b2c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2853 @@ -0,0 +1,55 @@ + +double-free in vmdk_add_extent() +Description of problem: +A double-free issue in the VMDK driver occurs when handling snapshots. +The memory allocated for extent structures is freed twice: first in +vmdk_close (block/vmdk.c) and then in vmdk_add_extent (block/vmdk.c). +Steps to reproduce: +1. [test.raw](/uploads/deeb9dc3cab1916adadd211173cd175a/test.raw) +2. ./qemu-img snapshot -q -a test test.raw +Additional information: +<details> +<pre> +./qemu-img snapshot -q -a test test.raw +==18180==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==18180==ERROR: AddressSanitizer: attempting double-free on 0x612000011bc0 in thread T0: + #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 + #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7) + #2 0x5605ba866a79 in vmdk_add_extent /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:570:18 + #3 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11 + #4 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20 + #5 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19 + #6 0x5605ba803ca4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20 + #7 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #8 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #9 0x5605ba4619f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +0x612000011bc0 is located 0 bytes inside of 272-byte region [0x612000011bc0,0x612000011cd0) +freed by thread T0 here: + #0 0x5605ba504aef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 + #1 0x5605ba857e6d in vmdk_close /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:2889:5 + #2 0x5605ba803bb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13 + #3 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #4 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +previously allocated by thread T0 here: + #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 + #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7) + #2 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11 + #3 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20 + #4 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19 + #5 0x5605ba56e3a2 in bdrv_open_driver /home/gerben/qemu-img_fuzz/build/../block.c:1660:15 + #6 0x5605ba57ea50 in bdrv_open_common /home/gerben/qemu-img_fuzz/build/../block.c:1985:11 + #7 0x5605ba57ea50 in bdrv_open_inherit /home/gerben/qemu-img_fuzz/build/../block.c:4153:11 + #8 0x5605ba585cb8 in bdrv_open /home/gerben/qemu-img_fuzz/build/../block.c:4248:12 + #9 0x5605ba637d4c in blk_new_open /home/gerben/qemu-img_fuzz/build/../block/block-backend.c:457:10 + #10 0x5605baa9193b in img_open_file /home/gerben/qemu-img_fuzz/build/../qemu-img.c:405:11 + #11 0x5605baa9143e in img_open /home/gerben/qemu-img_fuzz/build/../qemu-img.c:450:15 + #12 0x5605baa8cc71 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3468:11 + #13 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +SUMMARY: AddressSanitizer: double-free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 in realloc +==18180==ABORTING +</pre> +</details> diff --git a/results/classifier/accel-gemma3:12b/vmm/2862 b/results/classifier/accel-gemma3:12b/vmm/2862 new file mode 100644 index 000000000..d3675bdcb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2862 @@ -0,0 +1,25 @@ + +unable to complete install when i try to load into qemu +Description of problem: +when i load up a vm, i get the message Unable to complete install: 'internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install + installer.start_install(guest, meter=meter) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install + domain = self._create_guest( + ^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/lib/python3/dist-packages/libvirt.py", line 4481, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found. If it's important, vmm recognizes my windows 10 iso as a windows 11. +Steps to reproduce: +1.i just tried to use the vm. +2. +3. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2866 b/results/classifier/accel-gemma3:12b/vmm/2866 new file mode 100644 index 000000000..862255151 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2866 @@ -0,0 +1,186 @@ + +In Win98 vm gpu driver issues with old ati gpu if it has BAR0: 64 bit, BAR4: I/O; no issue if it has BAR0: 32 bit, BAR1: I/O +Description of problem: +In win98se vm no errors in device manager,ati control panel complains that the driver is not loaded and desktop can only be used in 16 color 640x480. The problematic old ati gpus work correctly when booting win98 directly(no qemu vm, same host hardware) + +Drivers fail to load in win98 vm for old ati gpu(x600, x700, x800, x850) that has: +``` + Region 0: Memory at 4020000000 (64-bit, prefetchable) [size=256M] + Region 2: Memory at 41b30000 (64-bit, non-prefetchable) [size=64K] + Region 4: I/O ports at 3000 [size=256] + Expansion ROM at 41b00000 [disabled] [size=128K] +``` +Old ati gpu(x300, x550) that have this, load/work correctly in win98 vm: +``` + Region 0: Memory at 40000000 (32-bit, prefetchable) [size=64M] + Region 1: I/O ports at 3000 [size=256] + Region 2: Memory at 45b30000 (32-bit, non-prefetchable) [size=64K] + Expansion ROM at 45b00000 [disabled] [size=128K] +``` +Additional information: +I am using a QEMU build from branch master from a few days ago, with a fix for segfault when using 'x-vga=on' on some old ati gpu(Region 0: Memory at 40000000 (32-bit),Region 1: I/O ports) https://gitlab.com/qemu-project/qemu/-/issues/2856. (Win98 gpu driver issues with old ati gpu if it has "BAR0: 64 bit, BAR4: I/O" was the same with QEMU version 9.12). + +x700: +``` +QEMU 9.2.50v9.2.0-2799-g0462a32b4f monitor> info pci: +Bus 0, device 2, function 0: + VGA controller: PCI device 1002:5e4d + PCI subsystem 148c:2129 + IRQ 10, pin A + BAR0: 64 bit prefetchable memory at 0xe0000000 [0xefffffff]. + BAR2: 64 bit memory at 0x00010000 [0x0001ffff]. + BAR4: I/O at 0xc000 [0xc0ff]. + BAR6: 32 bit memory at (not mapped) + id "" + Bus 0, device 2, function 1: + Display controller: PCI device 1002:5e6d + PCI subsystem 148c:2128 + BAR0: 64 bit memory at 0xfebf0000 [0xfebfffff]. + id "" +``` +``` +lspci -vv: + +08:00.0 0300: 1002:5e4d VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV410 [Radeon X700] (prog-if 00 [VGA controller]) + Subsystem: Tul Corporation / PowerColor Device 2129 + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin A routed to IRQ 16 + Region 0: Memory at 4020000000 (64-bit, prefetchable) [size=256M] + Region 2: Memory at 41b30000 (64-bit, non-prefetchable) [size=64K] + Region 4: I/O ports at 3000 [size=256] + Expansion ROM at 41b00000 [disabled] [size=128K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 25.000W + DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <2us + ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 40000001 00000003 000b0000 ffff0000 + Kernel driver in use: vfio-pci + Kernel modules: radeon, amdgpu + +08:00.1 0380: 1002:5e6d Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV410 [Radeon X700] (Secondary) + Subsystem: Tul Corporation / PowerColor Device 2128 + Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Region 0: Memory at 41b20000 (64-bit, non-prefetchable) [size=64K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W + DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <2us + ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Kernel driver in use: vfio-pci + Kernel modules: amdgpu +``` + +x550: +``` +QEMU 9.2.50v9.2.0-2799-g0462a32b4f monitor> info pci: +us 0, device 2, function 0: + VGA controller: PCI device 1002:5b63 + PCI subsystem 174b:1500 + IRQ 10, pin A + BAR0: 32 bit prefetchable memory at 0xef800000 [0xfbffffff]. + BAR1: I/O at 0xc000 [0xc0ff]. + BAR2: 32 bit memory at 0x00010000 [0xfebdffff]. + BAR6: 32 bit memory at (not mapped) + id "" + Bus 0, device 2, function 1: + Display controller: PCI device 1002:5b73 + PCI subsystem 174b:1501 + BAR0: 32 bit memory at 0xfebf0000 [0xfebfffff]. + id "" + + +lspci -vv: +08:00.0 1002:5b63 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300/X550/X1050 Series] (prog-if 00 [VGA controller]) + Subsystem: PC Partner Limited / Sapphire Technology Device 1500 + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin A routed to IRQ 16 + Region 0: Memory at 40000000 (32-bit, prefetchable) [size=64M] + Region 1: I/O ports at 3000 [size=256] + Region 2: Memory at 45b30000 (32-bit, non-prefetchable) [size=64K] + Expansion ROM at 45b00000 [disabled] [size=128K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 25.000W + DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us + ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 02000001 00000002 000003c8 037bbfae + Kernel driver in use: vfio-pci + Kernel modules: radeon, amdgpu + +08:00.1 1002:5b73 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300/X550/X1050 Series] (Secondary) + Subsystem: PC Partner Limited / Sapphire Technology Device 1501 + Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Region 0: Memory at 45b20000 (32-bit, non-prefetchable) [size=64K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W + DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us + ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Kernel driver in use: vfio-pci + Kernel modules: amdgpu +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2876 b/results/classifier/accel-gemma3:12b/vmm/2876 new file mode 100644 index 000000000..a5c08eeff --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2876 @@ -0,0 +1,15 @@ + +IPv6 support for hostfwd + guestfwd +Description of problem: +When using hostfwd, only IPv4 connections are forwarded. +Steps to reproduce: +1. Start vm with the aforementioned command using a system image that comes with a socket listening on both IPv4 and IPv6. (I used Arch Linux Box which comes with `sshd` enabled by default). +2. Connect to the forwarded socket: + - IPv4 succeeds: + - `ssh -oPasswordAuthentication=yes arch@127.0.0.1 -p 52022` + - `nc -zv 127.0.0.1 52022` + - IPv6 does not: + - `ssh -oPasswordAuthentication=yes arch@::1 -p 52022` + - `nc -zv ::1 52022` +Additional information: +# diff --git a/results/classifier/accel-gemma3:12b/vmm/2877 b/results/classifier/accel-gemma3:12b/vmm/2877 new file mode 100644 index 000000000..da5b85dd5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2877 @@ -0,0 +1,2 @@ + +Windows Hypervisor Acceleration does not work in Qemu 9.5.20 on Windows 11 24H2 Host diff --git a/results/classifier/accel-gemma3:12b/vmm/2882 b/results/classifier/accel-gemma3:12b/vmm/2882 new file mode 100644 index 000000000..79fd0569d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2882 @@ -0,0 +1,91 @@ + +Reading ACPI info via fw_cfg in SVSM causes Linux to panic +Description of problem: +We could use some help from a Qemu expert with an Qemu/ACPI/Linux related problem, +working on Coconut SVSM. + +**See https://github.com/coconut-svsm/svsm/issues/646** + +Coconut has code to read ACPI information via fw_cfg, and extract the number of guest CPUs from that. +That code has been used in the past, but since igvm became the default launch method for SVSM, it +was only used in corner-cases, while the information were obtained in some other way (igmv parameter). +Now a commit switches back to the fw_cfg+ACPI method. The information returned by it is correct, but +strangely Linux (guest) is spitting out ACPI related errors and crashes in some cases before reaching user-space. We do not have any clue how this can be related other than through Qemu behavior. +There is no direct way how SVSM can influence the ACPI related behavior of the Linux +guest kernel. + +The problem seems to be caused by simply reading the ACPI data. + +Reverting the bad commit and simply calling the original fw_cfg acpi function causes problems for Linux. +Steps to reproduce: +Boot SVSM bases CVM. SVSM and OVMF boot OK, then Linux prints these errors in some scenarios panics: +``` +[...] +[ 1.857709] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.859436] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.860867] ACPI Error: AE_BAD_ADDRESS, Unable to initialize fixed events (20240827/evevent-53) +[ 1.862709] ACPI: Unable to start the ACPI Interpreter +[ 1.863708] ACPI Error: Could not remove SCI handler (20240827/evmisc-251) +[ 1.864942] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MT +X_Namespace] (0x1) (20240827/utmutex-252) +[ 1.866715] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20240827/utmutex-252) +[ 1.869722] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20240 +827/utmutex-289) +[ 1.870826] iommu: Default domain type: Translated +[ 1.871710] iommu: DMA domain TLB invalidation policy: lazy mod +[...] +[ 2.672635] io scheduler bfq registered +[ 2.675679] atomic64_test: passed for x86-64 platform with CX8 and with SSE +[ 2.677596] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.679264] ------------[ cut here ]------------ +[ 2.680284] refcount_t: addition on 0; use-after-free. +[ 2.681477] WARNING: CPU: 3 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 +[ 2.683261] Modules linked in: +[ 2.683929] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.6-200.fc41.x86_64 #1 +[ 2.685608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202502-39-gb +483f751 02/02/2022 +[ 2.687729] RIP: 0010:refcount_warn_saturate+0xe5/0x110 +[ 2.688853] Code: e3 7f ff 0f 0b e9 fb 0a 8a 00 80 3d 15 9f 23 02 00 0f 85 5e ff ff ff 48 c7 c7 30 7b e7 8c c6 05 01 9f 23 02 01 e8 fb e2 7f ff <0f> 0b e9 d4 0a 8a 00 48 c7 c7 88 7b e7 8c + c6 05 e5 9e 23 02 01 e8 +[ 2.692768] RSP: 0018:ffffb2ed0001fd90 EFLAGS: 00010282 +[ 2.693894] RAX: 0000000000000000 RBX: ffff975b81060a80 RCX: ffffffff8d967448 +[ 2.695410] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001 +[ 2.696923] RBP: ffffb2ed0001fe38 R08: 0000000000000000 R09: 0720072007200720 +[ 2.698439] R10: 0720072007200720 R11: 0720072007200720 R12: ffff975b81060a80 +[ 2.699955] R13: ffffb2ed0001fe78 R14: 00000000000000dc R15: 00000000000001df +[ 2.701461] FS: 0000000000000000(0000) GS:ffff975cf7d80000(0000) knlGS:0000000000000000 +[ 2.703179] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 2.704400] CR2: 00007f1c1658a3c8 CR3: 000800006082c000 CR4: 00000000003506f0 +[ 2.705910] Call Trace: +[ 2.706451] <TASK> +[ 2.706922] ? srso_return_thunk+0x5/0x5f +[ 2.707820] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.708783] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.709712] ? kobject_get+0x68/0x70 +[ 2.710492] ? refcount_warn_saturate+0xe5/0x110 +[ 2.711480] ? __warn.cold+0x93/0xfa +[ 2.712268] ? refcount_warn_saturate+0xe5/0x110 +[ 2.713262] ? report_bug+0xff/0x140 +[ 2.714036] ? handle_bug+0x58/0x90 +[ 2.714779] ? exc_invalid_op+0x17/0x70 +[ 2.715617] ? asm_exc_invalid_op+0x1a/0x20 +[ 2.716526] ? refcount_warn_saturate+0xe5/0x110 +[ 2.717507] kobject_get+0x68/0x70 +[ 2.718266] kobject_add_internal+0x32/0x250 +[ 2.719196] kobject_add+0x96/0xc0 +[ 2.719923] kobject_create_and_add+0xa3/0xc0 +[ 2.720851] bgrt_init+0x77/0xc0 +[ 2.721578] ? __pfx_bgrt_init+0x10/0x10 +[ 2.722418] do_one_initcall+0x5b/0x310 +[ 2.723272] do_initcalls+0x147/0x170 +[ 2.724086] ? __pfx_kernel_init+0x10/0x10 +[ 2.725174] kernel_init_freeable+0xfb/0x130 +[ 2.726114] kernel_init+0x1a/0x140 +[ 2.726883] ret_from_fork+0x34/0x50 +[ 2.727679] ? __pfx_kernel_init+0x10/0x10 +[ 2.728580] ret_from_fork_asm+0x1a/0x30 +[ 2.729429] </TASK> +[ 2.729926] ---[ end trace 0000000000000000 ]--- +``` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2895 b/results/classifier/accel-gemma3:12b/vmm/2895 new file mode 100644 index 000000000..1475d5400 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2895 @@ -0,0 +1,31 @@ + +qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259) +Description of problem: +When I launch a Linux guest in QEMU with `-accel hvf` + `-gdb "tcp::1234"`, and I try to debug the kernel with `lldb`, QEMU crashes with the following report: + +``` +qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259) +``` +Steps to reproduce: +1. Run QEMU with `-accel hvf` + `-gdb "tcp::1234"` and a custom kernel (`-kernel Image`) +2. Try to attach using `lldb vmlinux` + `(lldb) gdb-remote 1234` +Additional information: +Debugging QEMU I see the crash is due to the `cpu->accel->fd` file descriptor being `0`: + +``` +warning: qemu-system-aarch64 was compiled with optimization - stepping may behave oddly; variables may not be available. +frame #4: 0x00000001003dd24c qemu-system-aarch64`hvf_arch_update_guest_debug [inlined] hvf_put_guest_debug_registers(cpu=0x0000000158118000) at hvf.c:2259:9 [opt] + 2256 for (i = 0; i < max_hw_bps; i++) { + 2257 r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbcr_regs[i], + 2258 env->cp15.dbgbcr[i]); +-> 2259 assert_hvf_ok(r); + 2260 r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbvr_regs[i], + 2261 env->cp15.dbgbvr[i]); + 2262 assert_hvf_ok(r); +(lldb) print cpu->accel->fd +(hvf_vcpuid) 0 +(lldb) print dbgbcr_regs[i] +(const uint16_t) 32773 +(lldb) print env->cp15.dbgbcr[i] +(uint64_t) 480 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/290 b/results/classifier/accel-gemma3:12b/vmm/290 new file mode 100644 index 000000000..0c82c908d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/290 @@ -0,0 +1,2 @@ + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM diff --git a/results/classifier/accel-gemma3:12b/vmm/2902 b/results/classifier/accel-gemma3:12b/vmm/2902 new file mode 100644 index 000000000..d3dd7978a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2902 @@ -0,0 +1,12 @@ + +Data Race with slh_first Field in test-aio-multithread +Description of problem: +Potential data races in the `QSLIST_INSERT_HEAD_ATOMIC` macro were identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-bdrv-drain +MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2919 b/results/classifier/accel-gemma3:12b/vmm/2919 new file mode 100644 index 000000000..4b90b1be4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2919 @@ -0,0 +1,14 @@ + +qemu-ga update resetting VssOption Registry key to default +Description of problem: +Before I installed the .exe from iso `virtio-win-0.1.271.iso`, I had value 5 in registry key `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption`. +After the driver update by the .exe, the value was set to 1. + +This registry key shouldn't change in driver update, as its value was manually set to 5 and it is important to preserve MSSQL backups in Proxmox. +Source: +https://blog.datact.ch/backup-mssql-server-with-proxmox +https://forum.proxmox.com/threads/pbs-breaking-customer-sql-backups-backups-without-fs-freeze.111526/ +Steps to reproduce: +1. Set a value to `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption` other than 1. +2. Install the .exe from version 0.1.271. +3. Check the key value. diff --git a/results/classifier/accel-gemma3:12b/vmm/2938 b/results/classifier/accel-gemma3:12b/vmm/2938 new file mode 100644 index 000000000..0fdbfa716 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2938 @@ -0,0 +1,12 @@ + +10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2 +Description of problem: +Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine. + +Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up. + +For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3. +Steps to reproduce: +1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2` +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2950 b/results/classifier/accel-gemma3:12b/vmm/2950 new file mode 100644 index 000000000..dc55592df --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2950 @@ -0,0 +1,66 @@ + +QEMU 10 breaks Incus' NVME handling +Description of problem: +Incus is an open-source container and VM manager. +For VMs we naturally use QEMU where we basically: + - Use QMP as much as possible to put together the VM prior to starting emulation + - Put the static pre-start stuff in a config file + use readconfig + - Keep the command line to a bare minimum + +This isn't particularly relevant to this issue except for the first point which is our use of QMP for most device handling. That means qemu is spawned without any disk or network attached. We have a `virtio-scsi` controller in the base config file but that's it. + +When doing NVME, we hotplug a new drive and a new nvme device pointing to that drive. +This means that our setup has a 1:1 mapping between NVME controllers on the PCIe bus and drives. + +This worked great up until QEMU 10. With QEMU 10, I believe this commit https://gitlab.com/qemu-project/qemu/-/commit/cd59f50ab017183805a0dd82f5e85159ecc355ce by @birkelund now effectively causes the creation of a `nvme-subsys` device when we add a `nvme` device without a pre-existing subsystem. + +As `nvme-subsys` doesn't support hotplugging, this immediately breaks all our VMs that rely on NVME. + +``` +stgraber@dakara:~$ incus start test-nvme +Error: Failed setting up device via monitor: Failed adding block device for disk device "root": Failed adding device: Device 'nvme-subsys' does not support hotplugging +Try `incus info --show-log test-nvme` for more info +``` + +As you can see, QEMU returns `Device 'nvme-subsys' does not support hotplugging`. + +On the QMP front, we did: +``` +stgraber@dakara:~$ sudo cat /var/log/incus/test-nvme/qemu.qmp.log +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"qom-get","arguments":{"path":"/machine","property":"type"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": "pc-q35-10.0-machine"} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-cpus-fast"} +[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"thread-id": 3885061, "props": {"core-id": 0, "thread-id": 0, "node-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"netdev_add","arguments":{"fds":"/dev/net/tun.0:/dev/net/tun.1","id":"incus_eth0","type":"tap","vhost":true,"vhostfds":"/dev/vhost-net.0:/dev/vhost-net.1"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":1,"bus":"qemu_pcie4","driver":"virtio-net-pci","id":"dev-incus_eth0","mac":"10:66:6a:30:97:66","mq":true,"netdev":"incus_eth0","vectors":6}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-add","arguments":{"aio":"native","cache":{"direct":true,"no-flush":false},"discard":"unmap","driver":"host_device","filename":"/dev/fdset/0","locking":"off","node-name":"incus_root","read-only":false}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":0,"bus":"qemu_pcie5","drive":"incus_root","driver":"nvme","id":"dev-incus_root","serial":"incus_root"}} +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-del","arguments":{"node-name":"incus_root"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-fdsets"} +[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"fds": [{"fd": 49, "opaque": "rdwr:incus_root"}], "fdset-id": 0}]} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"remove-fd","arguments":{"fdset-id":0}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} +``` +Additional information: +My limited understanding of NVME concepts is that NVME controllers are tied to a subsystem, then drives are tied to namespaces which themselves are tied to subsystems. + +So in a world where we need to deal with QEMU not supporting hotplugging subsystems, we would be able to create a single subsystem with a single controller and then hot plug/remove drives+namespaces into that. + +I've not actually tested this because to us it's not really an option. +We have users that for better or for worse currently rely on the current behavior of having each drive have its own controller, and so on the Linux side expect to see one PCIe device per drive and then one `/dev/nvmeXn1` device per drive. + +Changing this to be multiple namespaces on controller 0 would break anyone who ever hardcoded /dev/nvmeXn1 on their system and may also lead to different performance characteristics due to now using a single controller. Multiple controllers would still be an option of course, but they'd be tied to the same subsystem and namespaces so effectively now having the guest do NVME multipath. + + +Anyway, let me know if I'm missing a way to get QEMU 10 to behave as we did in releases prior, where I can start a VM with 0 NVME controllers, then add a couple of drives, each showing up as their own controller with the drive as namespace 1 on that. diff --git a/results/classifier/accel-gemma3:12b/vmm/2956 b/results/classifier/accel-gemma3:12b/vmm/2956 new file mode 100644 index 000000000..541b19574 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2956 @@ -0,0 +1,215 @@ + +AMD SEV-SNP: vhost-user-fs-pci iommu_platform=true is not supported by the device +Description of problem: +Trying to make use of `vhost-user-fs-pci` with `sev-snp-guest` enabled doesn't work. +The system reports that `vhost-user-fs-pci` doesn't support IOMMU but as far as I understand +we need IOMMU for the virtio protocol to fully function. +Steps to reproduce: +1. Ensure you are running on a system with AMD SNP support: +``` +sudo dmesg | grep -i sev +[ 0.000000] SEV-SNP: RMP table physical range [0x000000bfbd000000 - 0x000000c07d8fffff] +[ 0.003807] SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x000000c07d800000] +[ 8.085220] ccp 0000:06:00.5: sev enabled +[ 16.226155] ccp 0000:06:00.5: SEV API:1.55 build:28 +[ 16.226162] ccp 0000:06:00.5: SEV-SNP API:1.55 build:28 +[ 16.239284] kvm_amd: SEV enabled (ASIDs 15 - 1006) +[ 16.239289] kvm_amd: SEV-ES enabled (ASIDs 1 - 14) +[ 16.239292] kvm_amd: SEV-SNP enabled (ASIDs 1 - 14) +``` +2. Use an OVMF which supports AMD SNP: https://github.com/tianocore/edk2.git branch: edk2-stable202502 +3. Launch the virtiofs daemon process. +4. Launch qemu with device `vhost-user-fs-pci` +5. The qemu process will terminate with the following error message: + +``` +qemu-system-x86_64: -device vhost-user-fs-pci,chardev=fs0,tag=cfg: iommu_platform=true is not supported by the device +``` +Additional information: +It does launch if I disable any AMD SEV-SNP functionality from the VM: + +``` +sudo ./qemu-system-x86_64 \ + -nodefaults \ + -enable-kvm \ + -cpu host \ + -object memory-backend-memfd,id=mem0,size=2048M,share=on \ + -machine q35,memory-backend=mem0 \ + -smp cpus=1 \ + -drive file=ubuntu.qcow2,if=none,id=disk0,format=qcow2 \ + -device virtio-blk-pci,drive=disk0 \ + -device amd-iommu \ + -chardev socket,id=fs0,path=/var/run/virtiofs/cfg.sock \ + -device vhost-user-fs-pci,chardev=fs0,tag=cfg \ + -bios ./ovmf-dist/x86_64/OVMF.fd \ + -kernel ./linux-guest-6.12.15-1-/boot/vmlinuz-6.12.15-1 \ + -initrd ./initrd/initrd.img \ + -append 'console=ttyS0' \ + -display none + -nographic + -chardev stdio,id=stdio0,signal=off \ + -serial chardev:stdio0 \ + -D /tmp/qemu-vmm.log \ + -d 'guest_errors,unimp,trace:virtio*' +``` + +BTW: I've also managed to reproduce the same bug on AMD's fork: +- Repo: https://github.com/AMDESE/qemu.git +- Branch: snp-latest + +Configure flags: +``` + --target-list=x86_64-softmmu \ + --prefix=/builder/out/qemu-dist \ + --sysconfdir=/builder/out/qemu-dist/etc \ + --libdir=/builder/out/qemu-dist/lib \ + --libexecdir=/builder/out/qemu-dist/lib/qemu \ + --localstatedir=/builder/out/qemu-dist/var \ + --ninja=/usr/bin/ninja \ + --python=/usr/bin/python3 \ + --with-pkgversion=qemu \ + --cc=/usr/bin/x86_64-linux-gnu-gcc-13 \ + --static \ + --disable-cocoa \ + --disable-curses \ + --disable-dbus-display \ + --disable-gtk \ + --disable-gtk-clipboard \ + --disable-opengl \ + --disable-png \ + --disable-sdl \ + --disable-sdl-image \ + --disable-spice \ + --disable-spice-protocol \ + --disable-virglrenderer \ + --disable-vnc \ + --disable-vnc-jpeg \ + --disable-vnc-sasl \ + --disable-vte \ + --disable-alsa \ + --disable-coreaudio \ + --disable-dsound \ + --disable-jack \ + --disable-oss \ + --disable-pa \ + --disable-pipewire \ + --disable-sndio \ + --disable-vvfat \ + --disable-vdi \ + --disable-qed \ + --disable-qcow1 \ + --disable-bochs \ + --disable-cloop \ + --disable-dmg \ + --disable-parallels \ + --disable-vpc \ + --disable-vmdk \ + --disable-vhdx \ + --disable-bzip2 \ + --disable-lzfse \ + --disable-snappy \ + --disable-lzo \ + --disable-netmap \ + --disable-l2tpv3 \ + --disable-slirp-smbd \ + --disable-vde \ + --disable-vmnet \ + --disable-vhost-user-blk-server \ + --disable-vfio-user-server \ + --disable-curl \ + --disable-glusterfs \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-libssh \ + --disable-mpath \ + --disable-rbd \ + --disable-vduse-blk-export \ + --disable-virtfs \ + --disable-fuse \ + --disable-fuse-lseek \ + --disable-blkio \ + --disable-nettle \ + --disable-gcrypt \ + --disable-gnutls \ + --disable-crypto-afalg \ + --disable-libkeyutils \ + --disable-libkeyutils \ + --disable-auth-pam \ + --disable-keyring \ + --disable-selinux \ + --disable-u2f \ + --disable-brlapi \ + --disable-canokey \ + --disable-hvf \ + --disable-hv-balloon \ + --disable-libdaxctl \ + --disable-libudev \ + --disable-libusb \ + --disable-nvmm \ + --disable-rdma \ + --disable-smartcard \ + --disable-usb-redir \ + --disable-whpx \ + --disable-xen \ + --disable-xen-pci-passthrough \ + --disable-guest-agent \ + --disable-guest-agent-msi \ + --disable-colo-proxy \ + --disable-rutabaga-gfx \ + --disable-vhost-crypto \ + --disable-capstone \ + --disable-docs \ + --disable-gettext \ + --disable-iconv \ + --disable-libdw \ + --disable-pixman \ + --disable-sparse \ + --disable-xkbcommon \ + --disable-attr \ + --disable-gio \ + --disable-multiprocess \ + --disable-plugins \ + --disable-qpl \ + --disable-replication \ + --disable-uadk \ + --disable-libvduse \ + --disable-libpmem \ + --disable-user \ + --disable-bsd-user \ + --disable-linux-user \ + --disable-tcg \ + --disable-debug-tcg \ + --disable-tcg-interpreter \ + --disable-hexagon-idef-parser \ + --disable-qom-cast-debug \ + --enable-kvm \ + --enable-system \ + --enable-pie \ + --enable-lto \ + --enable-af-xdp \ + --enable-slirp \ + --enable-vhost-kernel \ + --enable-vhost-net \ + --enable-vhost-user \ + --enable-vhost-vdpa \ + --enable-bpf \ + --enable-coroutine-pool \ + --enable-linux-aio \ + --enable-linux-io-uring \ + --enable-malloc-trim \ + --enable-membarrier \ + --enable-cap-ng \ + --enable-seccomp \ + --enable-stack-protector \ + --enable-tpm \ + --enable-zstd \ + --enable-numa \ + --enable-fdt=disabled \ + --enable-install-blobs \ + --enable-tools \ + --enable-trace-backends=log \ + --enable-strip \ + --x86-version=4 \ + --extra-cflags=-O2 -fno-semantic-interposition -fdevirtualize-at-ltrans -flto=auto -fuse-linker-plugin -falign-functions=32 -D_FORTIFY_SOURCE=2 -Wno-deprecated-declarations -Wno-error=stringop-overflow -Wformat -Werror=format-security -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash-protection -fcf-protection -fipa-pta \ + --extra-ldflags=-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--as-needed +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/2960 b/results/classifier/accel-gemma3:12b/vmm/2960 new file mode 100644 index 000000000..efaa4ad77 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2960 @@ -0,0 +1,11 @@ + +Mouse doesn't work correctly with SDL display backend +Description of problem: +The mouse starts moving like crazy, up and down or left and right. +I tested it with -accel on and off, I make some test and seems to be the SDL display backed(GTK just crash before start execution of the vm). +Steps to reproduce: +1.Install Linux Mint 22.1 +2.Execute the command above. +3.Log in and the problems start. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2962 b/results/classifier/accel-gemma3:12b/vmm/2962 new file mode 100644 index 000000000..4b5397476 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2962 @@ -0,0 +1,23 @@ + +DHCP UDP checksum workaround code appears to be broken +Description of problem: +I am running dnsmasq DHCP server in an lxc-container. It is using a VETH pair for the network. The VETH device on the host is in a bridge. I create a TAP device and place it in the bridge. When booting the guest, I notice that the DHCP OFFER has an invalid UDP checksum all the way through the bridge and into the guest. I am able to fix this by disabling checksum offload inside the container, or adding an nftables rule that zeros out the checksum, or by reverting commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce. +Steps to reproduce: +1. From a debian 12 host, `apt-get install lxc lxc-templates` +2. `ip link add brtest type bridge` +3. `ip link set brtest up` +4. Create a container: `lxc-create -n dhcp -t debian -- --package=dnsmasq` +5. Edit the lxc container file `/var/lib/lxc/dhcp/config` and make sure the link is properly set to `lxc.net.0.link = brtest`, the type is set to `veth`, and give it an IP `lxc.net.0.ipv4.address = 192.168.255.1/24` +6. Start the container: `lxc-start -n dhcp` +7. Attach to the container: `lxc-attach -n dhcp` +8. Stop dnsmasq and networking: `systemctl stop dnsmasq.service networking.service` +9. Run a DHCP server: `dnsmasq --dhcp-authoritative --dhcp-range=192.168.255.2,192.168.255.254,255.255.255.0,1h --dns-loop-detect` +10. Exit the container: `exit` +11. Download the linux mint 22.1 installer: https://linuxmint.com/edition.php?id=319 +12. Create a TAP device and throw it in the bridge: `ip tuntap add dev taptest mode tap` .. `ip link set dev taptest up master brtest` +13. Run qemu: `qemu-system-x86_64 -enable-kvm -smp 4,sockets=1,threads=1 -machine pc-q35-9.2,accel=kvm,kernel_irqchip=on -m 4096 -device virtio-net-pci,netdev=nic91 -netdev tap,id=nic91,ifname=taptest,script=no,downscript=no -cdrom linuxmint-22.1-cinnamon-64bit.iso` .. I run it with vnc as this is on a headless server. +14. Once the guest has booted, you can run a tcpdump on the NIC and see that the guest receives the DHCP offer, but the UDP checksum is bunk. +Additional information: +I was able to test reverting the commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce and that appears to function once again. + +{width=901 height=38} diff --git a/results/classifier/accel-gemma3:12b/vmm/2963 b/results/classifier/accel-gemma3:12b/vmm/2963 new file mode 100644 index 000000000..b62bbb500 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2963 @@ -0,0 +1,25 @@ + +QEMU crash with `qemu_mutex_unlock_impl: Operation not permitted` during block device operations +Description of problem: +We got a crash when I use a blockdev-add command while a blockdev-backup operation was nearly complete. The crash does not reproduce consistently. + +This message was printed in the QEMU debug log. +`qemu: qemu_mutex_unlock_impl: Operation not permitted` + +We also collected a coredump at the time of the crash. but, when analyzing the coredump using gdb, the call stack only shows ?? for all frames, making it difficult to diagnose the root cause. + +so I have two main questions: + +1. Under what circumstances does `qemu_mutex_unlock_impl: Operation not permitted` occur? +Is there any known cause or workaround for this kind of crash? + +2. What should be done to ensure that the call stack in a coredump is visible? +Are there specific build flags or debug symbol requirements we should be aware of? +We built QEMU with --enable-debug, but the call stack still shows only ?? in gdb when analyzing the core dump. +Steps to reproduce: +1. Start a VM with block devices configured. +2. Begin a blockdev-backup operation. +3. Near the completion of the blockdev-backup, issue a blockdev-add command for another device. +4. Observe a crash. (The crash does not reproduce consistently) +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/2965 b/results/classifier/accel-gemma3:12b/vmm/2965 new file mode 100644 index 000000000..79c1e61f7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2965 @@ -0,0 +1,15 @@ + +crash when interacting with the UI in any way during record/replay mode on macOS +Description of problem: +``` +** +ERROR:../replay/replay-events.c:119:replay_add_event: assertion failed: (replay_mutex_locked()) +Bail out! ERROR:../replay/replay-events.c:119:replay_add_event: assertion failed: (replay_mutex_locked()) +fish: Job 1, 'qemu-system-x86_64 -icount shif…' terminated by signal SIGABRT (Abort) +``` +Steps to reproduce: +1. run the qemu command +2. click in the window +3. observe crash +Additional information: +[qemu-system-x86_64-2025-05-15-032037.ips](/uploads/2cccc7b967dacc8a18be8a3d0a0cf297/qemu-system-x86_64-2025-05-15-032037.ips) diff --git a/results/classifier/accel-gemma3:12b/vmm/2974 b/results/classifier/accel-gemma3:12b/vmm/2974 new file mode 100644 index 000000000..43a399c51 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2974 @@ -0,0 +1,2 @@ + +Remove the "51 Franklin Street, Fifth Floor, Boston" from the QEMU code base diff --git a/results/classifier/accel-gemma3:12b/vmm/2976 b/results/classifier/accel-gemma3:12b/vmm/2976 new file mode 100644 index 000000000..db292d20f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2976 @@ -0,0 +1,26 @@ + +attach-ns doesn't work correctly in SR-IOV, cannot attach NS to VF if it is attached to a PF +Description of problem: +We can't attach namespace to a VF (Secondary controller) unless it is not attached to a primary controller first + +Lately in the commit https://github.com/qemu/qemu/commit/6ccca4b6bb9f994cc04e71004e1767a3476d2b23 the file qemu/hw/nvme/ctrl.c got changed -\> in function "nvme_ns_attachment" -\> line 6819 (At the time I'm writing the bug) which is the condation in attach ns to check if the namespace is attached "`if (nvme_ns(n, nsid)) {`" + +This change will always result in checking the namespace attach to the PF even if we are trying to attach it to the VF. +Steps to reproduce: +1. Enable a VF: + +``` +echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset +sleep 1 + +echo 2 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs +sleep 1 + +nvme virt-mgmt /dev/nvme0 -c 1 -r 1 -a 8 -n 1 +nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 8 -n 2 +nvme virt-mgmt /dev/nvme0 -c 1 -a 9 +sleep 1 +``` + +2. attach namespace 1 to the PF (e.g. `vme attach-ns /dev/nvme0 -n1 -c0` ) +3. try to attach it using the nvme_cli command from the PF (e.g. `nvme attach-ns /dev/nvme0 -n1 -c1`) diff --git a/results/classifier/accel-gemma3:12b/vmm/2977 b/results/classifier/accel-gemma3:12b/vmm/2977 new file mode 100644 index 000000000..ab4d0e2f6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2977 @@ -0,0 +1,12 @@ + +QEMU SVM VMCB exit_code is uint32_t when AMD spec requires uint64_t +Description of problem: +QEMU's SVM implementation incorrectly uses a 32-bit parameter for the exit code in the `cpu_vmexit` function, despite the AMD SVM specification requiring a 64-bit exit code field in the VMCB (Virtual Machine Control Block). + +I think the issue is in `target/i386/svm.c` in the `cpu_vmexit` function. + +The `exit_code` parameter is declared as `uint32_t` but should be `uint64_t` according to the AMD SVM specification. This causes exit codes to be truncated to 32 bits, resulting in values like 0xffff_ffff instead of the expected 0xffff_ffff_ffff_ffff. +Steps to reproduce: + +Additional information: +[this](https://stackoverflow.com/questions/79632531/qemu-svm-vmcb-exit-code-is-uint32-t-when-amd-spec-requires-uint64-t?noredirect=1#comment140448815_79632531) question I posted on stack overflow diff --git a/results/classifier/accel-gemma3:12b/vmm/2981 b/results/classifier/accel-gemma3:12b/vmm/2981 new file mode 100644 index 000000000..6fb71a41e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/2981 @@ -0,0 +1,26 @@ + +Assert error with accel=hvf:tcg when hvf is unavailable +Description of problem: +Trying to start qemu with `-machine virt,accel=hvf:tcg` in a Mac OS guest under Mac OS host, both arm64. I expect it to try hvf (unavailable - nested virtualization not supported) and fallback to tcg. Documentation for accel option says "If there is more than one accelerator specified, the next one is used if the previous one fails to initialize." This works fine with kvm, but for hvf it crashes in some auxiliary function when trying it: + +``` +% qemu-system-aarch64 -machine virt,accel=hvf:tcg +qemu-system-aarch64: Error: ret = HV_UNSUPPORTED (0xfae9400f, at ../target/arm/hvf/hvf.c:949) +``` + +Stack trace +``` + * frame #0: 0x0000000193a18388 libsystem_kernel.dylib`__pthread_kill + 8 + frame #1: 0x0000000193a5188c libsystem_pthread.dylib`pthread_kill + 296 + frame #2: 0x000000019395ac60 libsystem_c.dylib`abort + 124 + frame #3: 0x00000001005ee7f4 qemu-system-aarch64`assert_hvf_ok_impl + 92 + frame #4: 0x000000010032a550 qemu-system-aarch64`hvf_arm_get_max_ipa_bit_size + 64 + frame #5: 0x0000000100334928 qemu-system-aarch64`virt_hvf_get_physical_address_range + 68 + frame #6: 0x00000001005ee9b8 qemu-system-aarch64`hvf_accel_init + 68 + frame #7: 0x00000001002ef8e4 qemu-system-aarch64`accel_init_machine + 92 + frame #8: 0x00000001002a6640 qemu-system-aarch64`do_configure_accelerator + 208 + frame #9: 0x0000000100782bdc qemu-system-aarch64`qemu_opts_foreach + 112 + frame #10: 0x00000001002a3180 qemu-system-aarch64`qemu_init + 11344 + frame #11: 0x00000001006ea76c qemu-system-aarch64`main + 36 + frame #12: 0x00000001936b2b4c dyld`start + 6000 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/316 b/results/classifier/accel-gemma3:12b/vmm/316 new file mode 100644 index 000000000..5504a846b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/316 @@ -0,0 +1,2 @@ + +[feature request] webcam support diff --git a/results/classifier/accel-gemma3:12b/vmm/323 b/results/classifier/accel-gemma3:12b/vmm/323 new file mode 100644 index 000000000..0d1a6cf89 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/323 @@ -0,0 +1,2 @@ + +qemu 5.2.0: Add reconnect option support for netdev socket diff --git a/results/classifier/accel-gemma3:12b/vmm/365 b/results/classifier/accel-gemma3:12b/vmm/365 new file mode 100644 index 000000000..8fd3422d6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/365 @@ -0,0 +1,2 @@ + +virtiofsd: Directory for PID file hardcoded diff --git a/results/classifier/accel-gemma3:12b/vmm/366 b/results/classifier/accel-gemma3:12b/vmm/366 new file mode 100644 index 000000000..563fc30bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/366 @@ -0,0 +1,2 @@ + +How to make OVMF diff --git a/results/classifier/accel-gemma3:12b/vmm/384 b/results/classifier/accel-gemma3:12b/vmm/384 new file mode 100644 index 000000000..6337db118 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/384 @@ -0,0 +1,2 @@ + +qemu-monitor-event command gets stuck randomly diff --git a/results/classifier/accel-gemma3:12b/vmm/416 b/results/classifier/accel-gemma3:12b/vmm/416 new file mode 100644 index 000000000..0c8c6e39b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/416 @@ -0,0 +1,2 @@ + +Error handling: Audit unsafe usages of strerror() diff --git a/results/classifier/accel-gemma3:12b/vmm/430 b/results/classifier/accel-gemma3:12b/vmm/430 new file mode 100644 index 000000000..895445399 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/430 @@ -0,0 +1,2 @@ + +Microsoft Hyper-V acceleration not working diff --git a/results/classifier/accel-gemma3:12b/vmm/431 b/results/classifier/accel-gemma3:12b/vmm/431 new file mode 100644 index 000000000..3b0230e2e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/431 @@ -0,0 +1,2 @@ + +USB passthrough in Windows Host non functional diff --git a/results/classifier/accel-gemma3:12b/vmm/433 b/results/classifier/accel-gemma3:12b/vmm/433 new file mode 100644 index 000000000..508f60099 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/433 @@ -0,0 +1,2 @@ + +chardev: Windows stdio eats characters diff --git a/results/classifier/accel-gemma3:12b/vmm/445 b/results/classifier/accel-gemma3:12b/vmm/445 new file mode 100644 index 000000000..e6bec8f69 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/445 @@ -0,0 +1,2 @@ + +QEMU + DOS keyboard behavior diff --git a/results/classifier/accel-gemma3:12b/vmm/462 b/results/classifier/accel-gemma3:12b/vmm/462 new file mode 100644 index 000000000..15f21b1bd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/462 @@ -0,0 +1,44 @@ + +mirror: the block-job-cancel command can put qemu to the endless error loop +Description of problem: +If the destination VM will crash (or network is down) right before the completion of the block device mirroring job (`block-job-cancel`), then there will be a possibility to put QEMU in the error loop. +Steps to reproduce: +1. Run both QEMU VMs: source + target. +2. On the target side prepare NBD server for blockdev mirroring process by using QMP commands similar to the one below: +``` +{"execute": "nbd-server-start", "arguments": { "addr": { "data": { "host": "::", "port": "49153" }, "type": "inet" } } } +{ "execute": "nbd-server-add", "arguments": { "device": "drive_main01", "writable": true } } +``` +3. On the source side, prepare VM for the migration and start driver mirror job: +``` +{"execute":"migrate-set-capabilities","arguments":{"capabilities":[{"capability":"pause-before-switchover","state":true}]}} +{ "execute": "drive-mirror", "arguments": { "device": "drive_main01", "mode": "existing", "job-id": "job0", "target": "nbd:127.0.0.1:49153:exportname=drive_main01", "sync": "top", "on-source-error": "stop", "on-target-error": "stop", "format": "raw", "speed": 0 } } +``` +4. On the source side wait for the `BLOCK_JOB_READY` event: +``` +{"timestamp": {"seconds": 1625586327, "microseconds": 833805}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 21474836480, "offset": 21474836480, "speed": 0, "type": "mirror"}} +``` +5. Start migration on the source side: +``` +{ "execute": "migrate", "arguments": { "uri": "tcp:127.0.0.1:8091" } } +``` +6. Wait for the `pre-switchover` state of the migration: +``` +{ "execute": "query-migrate" } +{"return": {"expected-downtime": 300, "status": "pre-switchover", "setup-time": 3, "total-time": 11343, "ram": {"total": 8725020672, "postcopy-requests": 0, "dirty-sync-count": 2, "multifd-bytes": 0, "pages-per-second": 39550, "page-size": 4096, "remaining": 2871296, "mbps": 1073.7734399999999, "transferred": 963647065, "duplicate": 1899491, "dirty-pages-rate": 84, "skipped": 0, "normal-bytes": 944705536, "normal": 230641}}} +``` +7. Kill target QEMU to reproduce an issue. +8. Cancel the job on the source side: +``` +{ "execute": "block-job-cancel", "arguments": { "device": "job0" } } +``` + +Got the endless errror loop: +``` +... +{"timestamp": {"seconds": 1625586487, "microseconds": 413847}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413865}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413885}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +... +``` +Source qemu could be stopped only by using SIGKILL. diff --git a/results/classifier/accel-gemma3:12b/vmm/469 b/results/classifier/accel-gemma3:12b/vmm/469 new file mode 100644 index 000000000..235d1ebca --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/469 @@ -0,0 +1,2 @@ + +SB16 audio playback freezes emulation in Windows 95 guest diff --git a/results/classifier/accel-gemma3:12b/vmm/471 b/results/classifier/accel-gemma3:12b/vmm/471 new file mode 100644 index 000000000..33dea7ec2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/471 @@ -0,0 +1,65 @@ + +Clipboard sharing with `qemu_vdagent` does not work with SDL backend +Description of problem: +Clipboard sharing doesn't work: qemu does not send clipboard-grab messages when selecting on the host, nor does it respond to clipboard-grab messages from the guest. +Steps to reproduce: +1. Start QEMU with `qemu_vdagent` and `-display sdl` +2. Try to copy on the host or the guest +3. Observe that the clipboard is not shared +Additional information: +It appears as though `vdagent_clipboard_notify` function is not called. + +Logs: + +With SDL: +``` +vdagent_open +vdagent_recv_chunk size 28 +vdagent_recv_msg msg announce-capabilities, size 8 +vdagent_peer_cap cap mouse-state +vdagent_peer_cap cap monitors-config +vdagent_peer_cap cap reply +vdagent_peer_cap cap clipboard-by-demand +vdagent_peer_cap cap clipboard-selection +vdagent_peer_cap cap sparse-monitors-config +vdagent_peer_cap cap guest-lineend-lf +vdagent_peer_cap cap max-clipboard +vdagent_peer_cap cap audio-volume-sync +vdagent_send msg announce-capabilities +# tried to copy on host -- nothing happens here. +# trying to copy on guest: +vdagent_recv_chunk size 28 +vdagent_recv_msg msg clipboard-grab, size 8 +vdagent_cb_grab_selection selection clipboard +vdagent_cb_grab_type type text +# no response sent +``` +With GTK: +``` +vdagent_open +vdagent_recv_chunk size 28 +vdagent_recv_msg msg announce-capabilities, size 8 +vdagent_peer_cap cap mouse-state +vdagent_peer_cap cap monitors-config +vdagent_peer_cap cap reply +vdagent_peer_cap cap clipboard-by-demand +vdagent_peer_cap cap clipboard-selection +vdagent_peer_cap cap sparse-monitors-config +vdagent_peer_cap cap guest-lineend-lf +vdagent_peer_cap cap max-clipboard +vdagent_peer_cap cap audio-volume-sync +vdagent_send msg announce-capabilities +# trying to copy on host: +vdagent_send msg clipboard-grab +vdagent_recv_chunk size 28 +vdagent_recv_msg msg clipboard-request, size 8 +vdagent_send msg clipboard +vdagent_recv_chunk size 28 +# trying to copy on guest: +vdagent_recv_msg msg clipboard-grab, size 8 +vdagent_cb_grab_selection selection clipboard +vdagent_cb_grab_type type text +vdagent_send msg clipboard-request +vdagent_recv_chunk size 29 +vdagent_recv_msg msg clipboard, size 9 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/488 b/results/classifier/accel-gemma3:12b/vmm/488 new file mode 100644 index 000000000..30fb397c4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/488 @@ -0,0 +1,31 @@ + +[git]Virt-Manager cannot start any previously created virtual machine with Qemu commit bd306cfe: 'spicevmc' is not a valid char driver name +Description of problem: +With qemu built on commit bd306cfe, I'm unable to start a previously created VM. + +Because of both bug #463 and #474 I was blocked from building qemu from git for something like a week or so. My last built and working Qemu is based on commit 9bef7ea9d9. + +Doing a git bissect won't be an easy task :( +Steps to reproduce: +1. Build qemu using commit bd306cfe +2. Launch Virt-Manager +3. Try to launch a previously created VM or try to boot a new one. +Additional information: +Every single time I tried to launch a VM, I get a dialog box with this error message: + +``` +Error starting domain: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/498 b/results/classifier/accel-gemma3:12b/vmm/498 new file mode 100644 index 000000000..0aaffc41f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/498 @@ -0,0 +1,43 @@ + +Cannot focus QEMU window on macOS Big Sur (11.4) +Description of problem: +I'm not sure when the problem has been started, but I recently noticed that key inputs to QEMU window are not processed and the input goes other focused windows (e.g. terminal). QEMU window itself is shown but it looks like they are not focused. Also, the Dock icon for QEMU is also disappeared (it was displayed before). +Steps to reproduce: +1. build & install the latest qemu with `./configure --target-list=x86_64-softmmu` + - (`a146af86c8247f41b641783428b95ee71eb0e43f` was the revision I used) +2. run `qemu-system-x86_64` from terminal +3. click the QEMU window. + - Expected behavior: menu bar title will be switched to "QEMU", key inputs are handled by QEMU, Dock icon will be shown. + - Actual behavior: menu bar shows different app name that were focused before clicking the qemu, key inputs went to other app that was focused, dock icon is not showing up. +Additional information: +I tried to see if the events are delivered to QemuCocoaView by putting `NSLog(@"handleEventLocked: %@\n", event);` at the beginning of `handleEventLocked` @ `ui/cocoa.m`. It looks like the mouse events are delivered but not NSEventTypeKeyDown. + +(logs after clicked the QEMU window and type some 'a') +``` +$ qemu-system-x86_64 +2021-07-24 16:58:00.767 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682409.7 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=4 data1=1144258560 data2=1138098176 +2021-07-24 16:58:00.768 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,228) time=682409.7 flags=0 win=0x7fe2b5fb0ee0 winNum=10356 ctxt=0x0 subtype=4 data1=1137180672 data2=1130627072 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1129 data2=0 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(591.031,166.896) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,0) time=0.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=1 data1=1129 data2=0 +2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=22 data1=0 data2=0 +2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=23 data1=0 data2=0 +2021-07-24 16:58:06.565 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(591.031,166.896) time=682415.5 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:12.997 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(174.184,408.859) time=682421.9 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:13.013 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(152.704,428.804) time=682422.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1131 data2=0 +2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(268.333,208.222) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:24.262 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(268.333,208.222) time=682433.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:24.877 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(3.83252,400.359) time=682433.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:25.053 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1 +2021-07-24 16:58:25.054 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0 +2021-07-24 16:58:25.302 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(10.917,420.558) time=682434.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:25.365 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(10.917,420.558) time=682434.3 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:25.845 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1 +2021-07-24 16:58:25.846 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0 +2021-07-24 16:58:25.855 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(14.2417,428.558) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 + +``` + +Possibly related discussion on Apple Developer Forums: +- https://developer.apple.com/forums/thread/667004 diff --git a/results/classifier/accel-gemma3:12b/vmm/498039 b/results/classifier/accel-gemma3:12b/vmm/498039 new file mode 100644 index 000000000..8255a5380 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/498039 @@ -0,0 +1,10 @@ + +No copy/paste with VNC display with Windows guest + +There is no copy/paste functionality between a Windows guest and the VNC client. This is a significant usability problem. + +One work-around is to run VNC inside of the guest. But that appears to have more overhead than qemu's VNC display. + +Obviously, qemu's VNC display is just a display device and knows absolutely nothing about the Windows clipboard. Thus, to interface with the guest's clipboard would require a helper app running in the guest that can hook into qemu. This would probably be the best solution. + +There are probably not a lot of qemu developers interested in trying to write the helper app. Not exactly an interesting job. But since it is a significant usability problem, and many users would see this as a major oversight, I suggest leaving this bug open long-term as a hint so that some volunteer later looking for something to do might take pity on everyone and write this helper app. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/498421 b/results/classifier/accel-gemma3:12b/vmm/498421 new file mode 100644 index 000000000..cf4b0bec6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/498421 @@ -0,0 +1,4 @@ + +Emulated monitor EDID reports too few available graphics resolutions + +In a Windows guest, not very many resolution modes are available. The available modes are restricted by what the virtual "monitor" EDID reports via DDC. And apparently, your fake monitor has a short list of modes. Please add some more modes like 1152x864, at least. But what would be REALLY nice is much finer granularity so that users can set the guest res to be just enough smaller than the host display so that window decorations and such fit. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/498523 b/results/classifier/accel-gemma3:12b/vmm/498523 new file mode 100644 index 000000000..3890f9c80 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/498523 @@ -0,0 +1,8 @@ + +Add on-line write compression support to qcow2 + +This is a wishlist item. Launchpad really need a way for the submitter to indicate this. + +It would be really cool if qemu were to support disk compression on-line for writes. + +I know this wouldn't be really easy. Although most OS's use blocks, you can really only count on being able to compress 512-byte sectors, which doesn't give much room for a good compression ratio. Moreover, the index indicating where in the image file each sector is located would be complex to manage, since the compressed blocks would be variable sized, and you'd be wanting to do some kind of best-fit allocation of space in the image file. (If you were to make the image file compressed block size granularity, say, 64 bytes, you could probably do this best fit O(1).) If you were to buffer enough writes, you could group arbitrary sequences of written sectors into blocks to compress (which with writeback could be sent to a helper thread on another CPU, so the throughput would be good). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/515 b/results/classifier/accel-gemma3:12b/vmm/515 new file mode 100644 index 000000000..f20a395d8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/515 @@ -0,0 +1,32 @@ + +qemu-system-x86_64 fails to run with regular user after following arch wiki article +Description of problem: +When `qemu-system-x86_64` binary is run with a regular user, it fails with no output. No matter if it's run with `--help`, `--version` or any other parameter. By checking the resulting error code (`echo $?`) it is possible to see that it finished with error code 1. + +After seeing this [post](https://www.reddit.com/r/archlinux/comments/b9emxp/qemusystemx86_64_does_not_execute_how_can_i/ek47btb/) on reddit, it became clear that the reason was that my `/etc` directory had a subdirectory qemu, in which my regular user did not have access to. That is, qemu binary looks for `/etc/qemu/qemu.conf` and if it can't determine if the file is there or not, it fails. + +Here goes the logic: +strace showed the permission error (even though there was no output to indicate that). + +``` +$ strace /usr/bin/qemu-system-x86_64 +… +mmap(NULL, 4928, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0) = 0x7f4d01e6e000 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0x10000000) = 0x7f4d01e6c000 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 4 +sysinfo({uptime=92539, loads=[109952, 80640, 118144], totalram=16643309568, freeram=5314445312, sharedram=2590158848, bufferram=1301561344, totalswap=20479733760, freeswap=19551150080, procs=1202, totalhigh=0, freehigh=0, mem_unit=1}) = 0 +rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f4d01ad7960}, NULL, 8) = 0 +openat(AT_FDCWD, "/etc/qemu/qemu.conf", O_RDONLY) = -1 EACCES (Permission denied) +exit_group(1) = ? ++++ exited with 1 +++ +``` + +The thing was that initially that folder did not exist, and I created it to make the qemu bridges work, like indicated in this arch wiki [article](https://wiki.archlinux.org/title/QEMU#Bridged_networking_using_qemu-bridge-helper). I will be suggesting modifications to that article. + +When the directory did not exit, qemu noticed that the folder didn't exist and moved on, once it was created, in case the regular user had no access to it, it fails with no warning. + +I just gave access to the folder ant it worked again (if you delete the folder it works too). + +If you use libvirt, by using virsh for example, you may not notice this issue as it may be running as system (by setting the following system variable `export LIBVIRT_DEFAULT_URI='qemu:///system'`) + +So, to fix this issue, in my opinion a warning should be printed out to the stderr. Otherwise, qemu could move on if it doens't have access to `/etc/qemu/qemu.conf`. diff --git a/results/classifier/accel-gemma3:12b/vmm/526 b/results/classifier/accel-gemma3:12b/vmm/526 new file mode 100644 index 000000000..2ddfc4998 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/526 @@ -0,0 +1,16 @@ + +MacBook German Keyboard <> and ^° Key not working +Description of problem: +Using a German keyboard on my 2018 MacBook Pro I can't type the <> Key or the ^ Key. +When pressing the <> Key it gets interpreted as the ^ Key, the ^ Key is dead. + +Problem is not caused by the guest system, Ubuntu VMs also can't type <>. (Ubuntu VMs ran inside UTM, which internally uses QEMU. https://mac.getutm.app/ ) + +VirtualBox maps the <> Key and ^ Key correctly. +Steps to reproduce: +0. Use a MacBook with a German Keyboard +1. Install TempleOS +2. Install German Keyboard Layout from https://github.com/Rion96/GKey (mount the ISO as a CD Drive) +3. Every key works except for <> and ^. +Additional information: +Doing the same steps in VirtualBox results in <> and ^ working, so it must be a QEMU error. diff --git a/results/classifier/accel-gemma3:12b/vmm/558 b/results/classifier/accel-gemma3:12b/vmm/558 new file mode 100644 index 000000000..79515e781 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/558 @@ -0,0 +1,58 @@ + +gtk UI interprets double/triple click as button release +Description of problem: +When using the GTK interface clicking rapidly in a down-up-down pattern, the final "down" event is erroneously followed by an immediate "up" event and the mouse device in the guest reports the pressed button as no longer being held. +Steps to reproduce: +1. Start a VM using the GTK interface. +2. Open a tool to examine guest mouse input events, such as `xev` or `yutani-test` +3. Click twice with any button, without releasing on the second click. +4. Observe erroneous 'up' event in guest. +5. Move the mouse while keeping the button pressed. +6. Observe the guest reports the button is not held. +Additional information: +GTK 3 sends an additional `GDK_2BUTTON_PRESS` event after the initial `GDK_BUTTON_PRESS` event, which QEMU is misinterpreting as a release event. I confirmed this with the addition of some logging of `button->type` in `gd_button_event`: + +``` +button = 1, type = 4 +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 7 +button = 1, type = 4 # = PRESS +button = 1, type = 5 # = 2BUTTON_PRESS +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 5 +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 7 +button = 1, type = 4 +button = 1, type = 5 +button = 1, type = 7 +``` + +```diff +diff --git a/ui/gtk.c b/ui/gtk.c +index cfb0728d1f..b9979f0e11 100644 +--- a/ui/gtk.c ++++ b/ui/gtk.c +@@ -925,6 +925,13 @@ static gboolean gd_button_event(GtkWidget *widget, GdkEventButton *button, + return TRUE; + } + ++ /* ignore additional events for double- and triple- press, as they are ++ * sent to us after a regular press event; otherwise we will misinterpret ++ * these as release events and eat the button! */ ++ if (button->type == GDK_2BUTTON_PRESS || button->type == GDK_3BUTTON_PRESS) { ++ return TRUE; ++ } ++ + qemu_input_queue_btn(vc->gfx.dcl.con, btn, + button->type == GDK_BUTTON_PRESS); + qemu_input_event_sync(); +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/561 b/results/classifier/accel-gemma3:12b/vmm/561 new file mode 100644 index 000000000..9a1d32fe7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/561 @@ -0,0 +1,2 @@ + +Q35 - ACPI PCI hot-plug issue with Windows guest diff --git a/results/classifier/accel-gemma3:12b/vmm/568 b/results/classifier/accel-gemma3:12b/vmm/568 new file mode 100644 index 000000000..4445aea20 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/568 @@ -0,0 +1,27 @@ + +video memory option not working with Mac OS or Windows guest +Description of problem: +The vgamem_mb option tells the guest how much video memory it has access to. When I used this command '-device VGA,vgamem_mb=128', I expect the guest to report there is 128 MB of video memory. What actually happens is the guest does not seem to know how much video memory is actually available. +Steps to reproduce: +**Mac OS guest:** +1. Run a Mac OS guest with this command: -device VGA,vgamem_mb=128 +2. In Mac OS X open the System Information application -> /Applications/Utilities/System Information. +3. Click on "Graphics/Displays". +4. Look at the 'VRAM (Total)' field. +The field only shows 3 MB of video ram. + +**Windows guest:** +1. Run a Windows (Windows XP in my case) guest with this command: -device VGA,vgamem_mb=128 +2. Click on Start->Run. +3. Enter 'dxdiag'. +4. Push the OK button. +5. Click on the Display tap in the DirectX Diagnostic Tool. +6. Look at the Approv. Total Memory field. +The field should say 128 MB but actually says N/A. +Additional information: +**Mac OS 8.5<br>** +<br><br><br> +**Windows XP<br>** +<br><br><br> +**Windows 7<br>** + diff --git a/results/classifier/accel-gemma3:12b/vmm/568614 b/results/classifier/accel-gemma3:12b/vmm/568614 new file mode 100644 index 000000000..a15060b15 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/568614 @@ -0,0 +1,17 @@ + +x86_64 host curses interface: spacing/garbling + +Environment: +Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3 + +Steps to reproduce: +1. Have a host system running 64-bit Linux. +2. Start a qemu VM with the -curses flag. + +Expected results: +Text displayed looks as it would on a real text-mode display, and VM is therefore usable. + +Actual results: +Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible. + +The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine. I don't know enough of the semantics of console_ch_t to know if this is the "correct" fix or if there should be, say, an extra cast somewhere instead. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/574 b/results/classifier/accel-gemma3:12b/vmm/574 new file mode 100644 index 000000000..c35b9c02d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/574 @@ -0,0 +1,2 @@ + +ui/sdl2: warning: redundant redeclaration of 'direct_waitqueue_init' diff --git a/results/classifier/accel-gemma3:12b/vmm/58 b/results/classifier/accel-gemma3:12b/vmm/58 new file mode 100644 index 000000000..529b2390b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/58 @@ -0,0 +1,2 @@ + +Bitmaps with Extra Data cannot be removed diff --git a/results/classifier/accel-gemma3:12b/vmm/581 b/results/classifier/accel-gemma3:12b/vmm/581 new file mode 100644 index 000000000..2c4b342b9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/581 @@ -0,0 +1,2 @@ + +QEMU should warn if the user passes a '-vga something' option and we ignore it diff --git a/results/classifier/accel-gemma3:12b/vmm/589315 b/results/classifier/accel-gemma3:12b/vmm/589315 new file mode 100644 index 000000000..fc1b69743 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/589315 @@ -0,0 +1,19 @@ + +qemu: Improve error reporting when migration can't connect + +Tested with upstream qemu as of Jun 3 2010 + +If the source qemu instance can't connect to the migration destination (say +there is no listening QEMU instance, or port is blocked by a firewall), all we +get is info migrate -> Migration status: failed. This is all we have to report +back to libvirt users if their firewall is misconfigured, which is crappy. + +Ideally, if we can't connect, migration would fail immediately with a relevant +message and strerror(). More info from 'info migrate' would be nice too, no +idea how this will play with QMP though. + +As a slightly related issue, try entering + +migrate tcp:127.0.0.0:6000 + +We get a 'migration failed' error, and then the monitor hangs! \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/592 b/results/classifier/accel-gemma3:12b/vmm/592 new file mode 100644 index 000000000..8cd3fb54a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/592 @@ -0,0 +1,109 @@ + +CloudLinux / CageFS - guest-fsfreeze hangs system +Description of problem: +Since CloudLinux provides CageFS (virtualized file system), each time guest-fsfreeze for Proxmox backup, the system is hangs up and become unavailable. It's caused by cagefs-skeleton mount points: + +``` +sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) +proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,gid=1002,hidepid=2) +devtmpfs on /dev type devtmpfs (rw,nosuid,size=3993656k,nr_inodes=998414,mode=755) +securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) +tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) +devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) +tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) +tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) +cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) +pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) +configfs on /sys/kernel/config type configfs (rw,relatime) +/dev/sda2 on / type ext4 (rw,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005) +mqueue on /dev/mqueue type mqueue (rw,relatime) +hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) +debugfs on /sys/kernel/debug type debugfs (rw,relatime) +fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) +/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered) +/usr/tmpDSK on /tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered) +/usr/tmpDSK on /var/tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered) +cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) +cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) +cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,relatime,cpuacct,cpu) +cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) +cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) +/dev/sda2 on /usr/share/cagefs-skeleton type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +devpts on /usr/share/cagefs-skeleton/dev/pts type devpts (rw,nosuid,relatime,gid=5,mode=620,ptmxmode=000) +/dev/sda2 on /usr/share/cagefs-skeleton/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/include type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/apache/domlogs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/perl type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Cpanel type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/base type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cgi-priv type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cpaddons type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/hooks type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/htdocs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/img-sys type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/install type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lang type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/libexec type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/scripts type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/shared type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/sys_cpanel/boxtrapper-message type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/var type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr/docroot/cgi/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.nodejs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.python type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/man type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/terminfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/vim type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/zoneinfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/cpanel/ea4 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/mysql type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/proxyexec/cagefs.sock type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/spamassassin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +tmpfs on /usr/share/cagefs-skeleton/run/dbus type tmpfs (rw,nosuid,mode=755) +tmpfs on /usr/share/cagefs-skeleton/run/nscd type tmpfs (rw,nosuid,mode=755) +/dev/sda2 on /usr/share/cagefs-skeleton/var/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/spool/at type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/www/cgi-bin type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/www/html type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/suphp/sbin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lve/lveinfo.ver.cagefs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +proc on /usr/share/cagefs-skeleton/proc type proc (rw,nosuid,relatime,gid=1002,hidepid=2) +systemd-1 on /usr/share/cagefs-skeleton/proc/sys/fs/binfmt_misc type autofs (rw,nosuid,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005) +tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=800880k,mode=700) +``` + +Is there anyway qemu-guest-agent can handle this? I saw a lot of users faced this problem since CloudLinux becomes more popular after RHEL halted future CentOS releases. + +CloudLinux has an option to umount/mount cagefs-skeleton, maybe it's something can be implemented - https://docs.cloudlinux.com/command-line_tools/ + +The same issue happens when JailShell is enabled on cPanel servers (OVH reported about) - https://docs.ovh.com/ca/en/vps/cpanel_auto_backup/ + +Thank you for your time. +Steps to reproduce: +1. Manually start backup for the VM with qemu-agent enabled. +2. The backup process stuck at "INFO: issuing guest-agent 'fs-freeze' command" +3. The VM become unavailable, you can only unlock it and force reset. diff --git a/results/classifier/accel-gemma3:12b/vmm/595 b/results/classifier/accel-gemma3:12b/vmm/595 new file mode 100644 index 000000000..56fb2e687 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/595 @@ -0,0 +1,12 @@ + +QEMU VNC mouse doesn't move in tablet mode os9 +Description of problem: +What I am trying to do is have a headless os9 running in QEMU on ubuntu and use the native vnc support in QEMU to access the screen. That is setup and works as expected but the mouse only works in ps/2 mode and that is clearly very undesirable (mouse is never lined up). I set it up in tablet mode and when I am in the QEMU window on the host the mouse works perfect (I added tablet mode to os9 with: https://github.com/kanjitalk755/macos9-usb-tablet). That same tablet mode results in the mouse not moving at all over vnc, if I ctrl+alt 2 and switch the mouse type from tablet mode it starts working again but not lined up at all as expected, cant get to any buttons on edges. Is there anyone in here that ran into this? Am I the only one using QEMU VNC? + +Iv thought about running a vnc application on the vm itself but performance was meh at best. Any tips would be worth a lot to me, its a sin to say but I am trying to adapt this into a production environment... + +Upon further investigation this seems to be a issue on Linux. I am testing the QEMU on windows and its working as expected over VNC. That is to say if QEMU is running on a windows host, it just works over vnc with tablet mode. So what could be causing Linux version to not work? I did compile it from source, are there any configure flags I am missing? I am trying to run it on Ubuntu server 21.04 +Steps to reproduce: +1.add vnc option to parameters +2.enable tablet mode and install driver in os9 +3.connect to vnc and mouse doesn't move diff --git a/results/classifier/accel-gemma3:12b/vmm/601946 b/results/classifier/accel-gemma3:12b/vmm/601946 new file mode 100644 index 000000000..b49c5b4fa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/602544 b/results/classifier/accel-gemma3:12b/vmm/602544 new file mode 100644 index 000000000..123e04d04 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/602544 @@ -0,0 +1,7 @@ + +[Feature request] Please implement ATA TRIM command + +Modern linuxes can use ATA TRIM command on block devices. It will be very nice if qemu translates this request to underlying block driver. + +1. So, if I use RAW image (on my case - lvm partition), TRIM inside qemu should do TRIM command on my readl HDD +2. In the future, TRIM command inside qemu will free space inside qcow images. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/614958 b/results/classifier/accel-gemma3:12b/vmm/614958 new file mode 100644 index 000000000..265303b87 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/614958 @@ -0,0 +1,38 @@ + +copy-paste between client and host + +Hi, + +I propose that copy/paste between VMs be implemented somehow directly in QEMU. +This has been discussed repeatedly elsewhere; various solutions are proposed. See below. + +As it is, each user has to do their own research and testing if they are to find a solution. This makes the product frustratingly unattractive for many. + +Most solutions involve either running vnc and using a vnc client that supports copy/paste (this can be tricky to find itself), or running some other tcp-based copy-paste application. + +For many users, the networking in a client VM is unimportant--they just want to run some application there, and setting up netoworking in a VM itself can be an issue. Most of these solutions rely on un-maintained software, and some require that other software be installed to make them work (Basic interpreter, Java, etc). Any of these solutions take some work to set up. + +I can tell you, the absence of a copy/paste mechanism makes the project an immediate no-go for many users. I work with a guy who spent a lot of time trying, gave up, and switched to VirtualBox for this exact reason. + +It would be much better if copy/paste worked out of the box. Ideally, it should work independently of networking. + +Cheers! + +Some discussions and proposed solutions: +----------------------------------------------------- +http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=161 + Somebody suggests VNC into the virtual host, and use vncviewer + Somebody else suggests TCP/IP Clipboard (text editor with tcp/ip) + +http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=2626 + primitive app for sharing text across machines (in Basic) + http://homepage.mac.com/bnej/shareclip/ + +http://borderworlds.dk/blog/20070217-00.html + Says doesn't know a good solution but points to unmaintained package + Qemu Guest Tools + http://wolfpackally.wo.funpic.de/qemu/qgt/ + +http://bonzoli.com/docs/How_to_setup_Qemu_on_Fedora_8.html + proposes Java remoteclip running on client and server + http://www.cs.cmu.edu/afs/cs/user/rcm/WWW/RemoteClip/ \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/617 b/results/classifier/accel-gemma3:12b/vmm/617 new file mode 100644 index 000000000..76256aaba --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/617 @@ -0,0 +1,27 @@ + +USB passthrough with Conbee 2 failing after upgrade to Fedora 34 / Libvirt 7.0.0 +Description of problem: +Hi, + +I upgraded recently from Fedora 32 to 34. + +For a little under a year, I've been running reliably a Home Assistant instance with Deconz add-on in a VM, with a Conbee 2 zigbee gateway in USB passthrough, controlling about 15 devices (door/window sensors, thermometers, leak sensors and push buttons). + +It has worked flawlessly but stopped working after upgrading Fedora. The Conbee shows up on the Linux guest but the serial can't be read by the Deconz application and it just does not work, the app can't get past the device connection screen. + +This is the state of what works and what doesn't: + +- Home Assistant Linux VM: NOK +- Ubuntu Linux 20.04 VM: NOK +- Windows 10 VM: NOK +- Windows 10 physical machine: OK, can connect and pair a door sensor + +All running the latest Deconz app. + +The fact that the physical Windows machine works excludes a bricked device. I used the physical Windows to upgrade the Conbee 2 firmware with no improvement. + +This does not seem to be an isolated issue: https://old.reddit.com/r/homeassistant/comments/o04sgw/conbee_ii_usb_passthrough_with_libvirt_660/ + +Apologies if this has already been reported. Let me know what kind of logs you might want. + +Thanks! diff --git a/results/classifier/accel-gemma3:12b/vmm/623 b/results/classifier/accel-gemma3:12b/vmm/623 new file mode 100644 index 000000000..c54982c45 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/623 @@ -0,0 +1,9 @@ + +Allow direct access to windows disks on hyper-V as well as virtiofsd, DAX +Additional information: +Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression. +``` +J:\>E:\scoopg\shims\qemu-system-x86_64.exe --version +QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/628 b/results/classifier/accel-gemma3:12b/vmm/628 new file mode 100644 index 000000000..80ff28afb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/628 @@ -0,0 +1,9 @@ + +nested virtualization on whpx +Additional information: +Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression. +``` +PS J:\> E:\scoopg\shims\qemu-system-x86_64.exe --version +QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/628082 b/results/classifier/accel-gemma3:12b/vmm/628082 new file mode 100644 index 000000000..f2657a338 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/628082 @@ -0,0 +1,8 @@ + +nl-be keymap is wrong + +As mentioned on https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/429965 as well as the kvm mailinglist (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/14413), the nl-be keymap does not work. The number keys above the regular keys (non-numeric keypad numbers) as well as vital keys such as slash, backslash, dash, ... are not working. + +The nl-be keymap that is presented in the above URLs (and also attached to this bug) does work properly. + +Would it be possible to include this keymap rather than the current one? \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/631 b/results/classifier/accel-gemma3:12b/vmm/631 new file mode 100644 index 000000000..57a8782ac --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/631 @@ -0,0 +1,26 @@ + +QEMU locks out user interface after waking from laptop sleep +Description of problem: +If qemu is started on laptop from command line and set to full screen, screen activated with mouse click, then put to sleep by closing lid; after waking up by opening lid the user interface locks out, the mouse cursor doesn't show, mouse clicks and keys are unresponsive. + +A Ctrl-ALt-Fn terminal must then be used to locate and kill the qemu process. After which the system can recover if it is terminated. The system tends to be affected in other ways such as wifi being disabled and needs to manually enabled after. So it looks like it disrupts the system from fully restoring the awoken state. + +The terminal from which QEMU is running is also filled with debug output. The issue looks to be caused by the SDL backend not knowing what to do with a wake up code. The terminal window is filled with the following text: +`The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 151 (143), X11 KeySym 0x1008FF2B (XF86WakeUp).` + +I have reduced the steps causing the bug to as little as needed with low dependencies. +Steps to reproduce: +1. Using a laptop, start a qemu session in full screen like so: + `./qemu-system-ppc -machine mac99,via=pmu -serial stdio -full-screen` +2. Shut the lid so it sleeps. +3. Shortly after open the lid. +Additional information: +I downloaded the 6.1.0 stable build and compiled it myself. + +The SDL issue appears to be low priority. I found some reports here but see no evidence of it being discussed. +https://discourse.libsdl.org/t/key-not-recognised-by-sdl/24181 + + + + + diff --git a/results/classifier/accel-gemma3:12b/vmm/636095 b/results/classifier/accel-gemma3:12b/vmm/636095 new file mode 100644 index 000000000..3c55402b7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/636095 @@ -0,0 +1,43 @@ + +tap downscript is not executed when exiting qemu through "quit" monitor command + +When you tell qemu to shutdown using the "quit" monitor command, the downscript of the tap interface is not executed. + + +To reproduce: + + +Create the test script /tmp/qemu-ifdown-test.sh : + +== +#!/bin/bash + +touch /tmp/is_this_working +== + +Run: + +== +# chmod +x /tmp/qemu-ifdown-test.sh +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# nc -U /tmp/monitor.socket +QEMU 0.12.5 monitor - type 'help' for more information +(qemu) quit +quit +# ls /tmp/is* +ls: cannot access /tmp/is*: No such file or directory + +== + +If I quit qemu by sending a SIGTERM instead of using the "quit" command, the downscript does get executed: + +== +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# killall qemu-system-x86_64 +# ls /tmp/is* +/tmp/is_this_working +== + +Issue occurs with both 0.12.3 and 0.12.5 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/646 b/results/classifier/accel-gemma3:12b/vmm/646 new file mode 100644 index 000000000..87ac7b5a1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/646 @@ -0,0 +1,19 @@ + +Infinite loop in xhci_ring_chain_length() in hw/usb/hcd-xhci.c (CVE-2020-14394) +Description of problem: +An infinite loop issue was found in the USB xHCI controller emulation of QEMU. Specifically, function `xhci_ring_chain_length()` in hw/usb/hcd-xhci.c may get stuck while fetching empty TRBs from guest memory, since the exit conditions of the loop depend on values that are fully controlled by guest. A privileged guest user may exploit this issue to hang the QEMU process on the host, resulting in a denial of service. +Steps to reproduce: +Build and load `xhci.ko` from within the guest: + +1) make +2) insmod xhci.ko + +[Makefile](/uploads/98dbf7b4facc9b100817b3c8f63b5cb2/Makefile) + +[usb-xhci.h](/uploads/f225524b1553d8cf6c1dfa89369b6edc/usb-xhci.h) + +[xhci.c](/uploads/c635f742d12a2bba6ea472ddfe006d56/xhci.c) +Additional information: +This issue was reported by Gaoning Pan (Zhejiang University) and Xingwei Li (Ant Security Light-Year Lab). + +RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1908004. diff --git a/results/classifier/accel-gemma3:12b/vmm/650 b/results/classifier/accel-gemma3:12b/vmm/650 new file mode 100644 index 000000000..2abb430ed --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/650 @@ -0,0 +1,25 @@ + +Monitor device_add triggers deadlock when calling drain_call_rcu on QEMU >= 6.0.0 +Description of problem: +It hangs +Steps to reproduce: +1. Run the QEMU: + ``` + ./qemu-system-mips64 -nographic + ``` +2. Enter into the QEMU monitor: press ctrl-a c +3. Execute command `device_add` without arguments: +``` +(qemu) device_add +``` +4. It hangs so bad that only `kill -9` helps +Additional information: +I didn't test versions between 4.2.0 and 6.0.0, but I can confirm that 6.0.0, 6.1.0 and the latest master pull have this bug, while version 4.2.0 doesn't have it. + +I've tracked the problem and found this. + +1. Command `device_add` calls function `drain_call_rcu`. `drain_call_rcu` waits indefinitely for drain_complete_event. +2. Function `cpu_exec` in accel/tcg/cpu-exec.c calls `rcu_read_lock` but does not call `rcu_read_unlock()`. `cpu_exec` just spins in its inner loop. +3. Function `call_rcu_thread` hanged in calling the `synchronize_rcu` which calls `wait_for_readers`. + +If I execute `stop` command in QEMU monitor before calling `device_add` command, no hang happen. diff --git a/results/classifier/accel-gemma3:12b/vmm/664 b/results/classifier/accel-gemma3:12b/vmm/664 new file mode 100644 index 000000000..dcb67192d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/664 @@ -0,0 +1,15 @@ + +hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID +Description of problem: +When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors. +Steps to reproduce: +This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines: +``` +[Kernel]: CPU[0]: Physical address bit width: 36 +[Kernel]: CPU[0]: Virtual address bit width: 32 +``` +But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001. +Additional information: +The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values. + +NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information. diff --git a/results/classifier/accel-gemma3:12b/vmm/665743 b/results/classifier/accel-gemma3:12b/vmm/665743 new file mode 100644 index 000000000..05c2768cb --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/665743 @@ -0,0 +1,4 @@ + +Cocoa video corruption when guest uses RGB565 mode + +The cocoa video driver doesn't currently support when the guest uses RGB565 or HighColor mode resulting in corrupted video. The initial graphics screen of recent Ubuntu installs is an example. The attached patch against 0.13.0-release seems to fix the problem by introducing an indirect data provider that translates from RGB565 to RGB888, a mode that core graphics supports. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/666 b/results/classifier/accel-gemma3:12b/vmm/666 new file mode 100644 index 000000000..2341cb70f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/666 @@ -0,0 +1,8 @@ + +ivshmem-plain cannot be used on non-Linux hosts +Additional information: +I would like to propose this patch as-is on the mailing list (the trivial one?) as soon as I figure patch submission out fully: + +https://github.com/fredldotme/qemu/commit/e929b8db8078aede6df7b02d8c0b71d1e2d6afcb + +It's just `#ifdef`ing out doorbell support on non-Linux builds which seems to be enough for basic functionality. diff --git a/results/classifier/accel-gemma3:12b/vmm/667 b/results/classifier/accel-gemma3:12b/vmm/667 new file mode 100644 index 000000000..4270d5fca --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/667 @@ -0,0 +1,2 @@ + +Wacom EMR pen pressure support diff --git a/results/classifier/accel-gemma3:12b/vmm/676934 b/results/classifier/accel-gemma3:12b/vmm/676934 new file mode 100644 index 000000000..8d2c8458a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/676934 @@ -0,0 +1,9 @@ + +Ability to use -net socket with unix sockets + +It would be a nice feature (simplifying access control for example) to be able to do something like: + +qemu -net socket,listen=unix:/tmp/qemunet +qemu -net socket,connect=unix:/tmp/qemunet + +For now one has to use TCP connections even for guests running on the same host, which involves setting up iptables to restrict access. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/678 b/results/classifier/accel-gemma3:12b/vmm/678 new file mode 100644 index 000000000..814dbd185 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/678 @@ -0,0 +1,48 @@ + +eject (monitor command) not work for blockdev cdrom +Description of problem: +cdrom1 device work fine, all files reads, but when i whant to eject CD-ROM disk from device by telnet monitor, it not work. +Steps to reproduce: +1. Connect to monitor with +``` +telnet 127.0.0.1 9100 +(QEMU 5.2.0 monitor - type 'help' for more information) +``` + +2. Show block devices +``` +info block +cdrom1-format: /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only) + Attached to: cdrom1 + Removable device: not locked, tray closed + Cache mode: writeback +``` + +3. Send eject commands +``` +eject cdrom1 +Error: Device 'cdrom1' not found +eject cdrom1-format +Error: Device 'cdrom1-format' not found +eject cdrom1-storage +Error: Device 'cdrom1-storage' not found +``` +Additional information: +When i run qemu with next lines (replace -blockdev to -drive): +``` +-device ide-cd,bus=ide.1,drive=cdrom1,id=idecd1,bootindex=2 +-drive if=none,id=cdrom1,media=cdrom,readonly=on,file="/mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso" +``` + +eject cdrom1 command work fine + +``` +info block +cdrom1 (#block133): /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only) + Attached to: idecd1 + Removable device: not locked, tray closed + Cache mode: writeback +eject cdrom1 +``` + +Also i found a similar bug description on this link https://bugs.launchpad.net/qemu/+bug/1799766 diff --git a/results/classifier/accel-gemma3:12b/vmm/678363 b/results/classifier/accel-gemma3:12b/vmm/678363 new file mode 100644 index 000000000..41c95999c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/678363 @@ -0,0 +1,12 @@ + +Swapping caps lock and control causes qemu confusion + +Running Fedora14 [host], I have caps-lock and control swapped over in my keyboard preferences. + +Qemu doesn't cope very well with this; running an OS inside Qemu (again fedora, suspect that it doesn't matter): + +The physical caps-lock key [which the host uses as control] toggles caps-lock on both press and release. + +The physical control key [which the host uses as caps-lock], acts as both a caps-lock and control key. + +Qemu should either respect my keyboard layout or else ignore it completely. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/68 b/results/classifier/accel-gemma3:12b/vmm/68 new file mode 100644 index 000000000..f8e82fa05 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/68 @@ -0,0 +1,2 @@ + +Solaris can't be powered off with ACPI shutdown/poweroff diff --git a/results/classifier/accel-gemma3:12b/vmm/681 b/results/classifier/accel-gemma3:12b/vmm/681 new file mode 100644 index 000000000..d283db35e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/681 @@ -0,0 +1,26 @@ + +Error saving memory to disk +Description of problem: +When trying to save the state of the machine using virt-manager (3.2.0) it fails with this error: + +Error saving domain: operation failed: domain save job: unexpectedly failed +```bash +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/vmmenu.py", line 182, in cb + vm.save(meter=asyncjob.get_meter()) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1377, in save + self._backend.managedSave(0) + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1780, in managedSave + raise libvirtError('virDomainManagedSave() failed') +libvirt.libvirtError: operation failed: domain save job: unexpectedly failed +``` +Steps to reproduce: +1. setup a virtual machine +2. setup a linux distro +3. try to save the memory to disk +Additional information: +Will be provided when needed diff --git a/results/classifier/accel-gemma3:12b/vmm/686613 b/results/classifier/accel-gemma3:12b/vmm/686613 new file mode 100644 index 000000000..00d2786a4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/686613 @@ -0,0 +1,6 @@ + +USB MSD are not marked as removable + + Filed from Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=589130 + +Guests can access USB Mass Storage Device, but fail to mark them as removable. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/688 b/results/classifier/accel-gemma3:12b/vmm/688 new file mode 100644 index 000000000..6e74f6503 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/688 @@ -0,0 +1,48 @@ + +Shrinking an image with qemu-img does not reduce image file size +Description of problem: +I have a macOS 10.9 VM using a qcow2 image that was 151GB. The image was originally converted from a VMware image with: +``` +qemu-img convert macOS-10.9.vmdk -O qcow2 -o preallocation=falloc macOS-10.9.qcow2 +``` +This resulted in `macOS-10.9.qcow2` being 151GB big: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +After reducing the filesystem size from within macOS to 25GB with DiskUtil, I shut down the VM and resized the image to 30GB with: +``` +qemu-img resize -f qcow2 --shrink macOS-10.9.qcow2 30G +``` +This succeeded. However, the file still consumes 151GB of space: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +Even though `qemu-img info` shows: +``` +$ qemu-img info macOS-10.9.qcow2 +image: macOS-10.9.qcow2 +file format: qcow2 +virtual size: 30 GiB (32212254720 bytes) +disk size: 30 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false +``` +The size inside the VM is also reported as being 30GB. + +The whole point of resizing that image was to free up disk space on the host. But this doesn't seem to be happening. + +My filesystem is ext4. +Steps to reproduce: +1. Create a vmdk image with `qemu-img create -f vmdk test.vmdk 5G` +2. Convert the vmdk image to qcow2 with `qemu-img convert test.vmdk -O qcow2 -o preallocation=falloc test.qcow2` +3. Shrink the new image with `qemu-img resize -f qcow2 --shrink test.qcow2 3G` + +The resulting `test.qcow2` file should be 3GB, but it's not. It's 5GB. diff --git a/results/classifier/accel-gemma3:12b/vmm/689 b/results/classifier/accel-gemma3:12b/vmm/689 new file mode 100644 index 000000000..f3b431b14 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/689 @@ -0,0 +1,34 @@ + +Unable To Open UDP Port +Description of problem: +Unable to forward UDP port +Steps to reproduce: +Used **..\qemu-system-x86_64.exe" -smp 4 -accel whpx -hda ".\ubuntu01.qcow2" -m 8G -vga std -net nic -net user,hostfwd=tcp::80-:80,hostfwd=tcp::443-:443,hostfwd=tcp::10000-:10000,hostfwd=udp::10000-:10000**__ to run qemu. +Additional information: +I want to use 10000(UDP) port at my server i used upper command to run my Qemu server as i was using it for TCP ports. Here are the logs: +<br/> +**AT Guest(UBUNTU):**<br/> +10000/tcp ALLOW Anywhere<br/> +10000/udp ALLOW Anywhere<br/><br/> + +**AT Host(Windows):**<br/> +_**FOR TCP 10000 (IT'S WORKING)**_<br/> + Starting portqry.exe -n 127.0.0.1 -e 10000 -p TCP ...<br/> +Querying target system called:<br/> + 127.0.0.1<br/> +Attempting to resolve IP address to a name...<br/> +IP address resolved to DESKTOP-Node001<br/> +querying...<br/> +TCP port 10000 (unknown service): LISTENING<br/> +portqry.exe -n 127.0.0.1 -e 10000 -p TCP exits with return code 0x00000000.<br/><br/> + + +_**FOR UDP 10000 (IT'S NOT WORKING)**_<br/> +Starting portqry.exe -n 127.0.0.1 -e 10000 -p UDP ...<br/> +Querying target system called:<br/> + 127.0.0.1<br/> +Attempting to resolve IP address to a name...<br/> +IP address resolved to DESKTOP-Node001<br/> +querying...<br/> +UDP port 10000 (unknown service): LISTENING or FILTERED<br/> +portqry.exe -n 127.0.0.1 -e 10000 -p UDP exits with return code 0x00000002.<br/> diff --git a/results/classifier/accel-gemma3:12b/vmm/69 b/results/classifier/accel-gemma3:12b/vmm/69 new file mode 100644 index 000000000..8c8df439f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/69 @@ -0,0 +1,2 @@ + +ALSA underruns occurr when using QEMU diff --git a/results/classifier/accel-gemma3:12b/vmm/690776 b/results/classifier/accel-gemma3:12b/vmm/690776 new file mode 100644 index 000000000..0aa5abcc9 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/690776 @@ -0,0 +1,6 @@ + +Overwrite argv to set process title, eliminating 16-character prctl() limit. + +I've modified qemu to overwrite its arguments to set the process title, since its current prctl() method has a 16-character limit. + +I posted the original patch to qemu-devel, made the changes others suggested, then re-posted to qemu-devel. I flailed around a bit with the patch submission process and think I finally got it right, but haven't been able to gain the notice of a committer to have this pushed. Maybe this will get more attention when reported in the BTS. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/692 b/results/classifier/accel-gemma3:12b/vmm/692 new file mode 100644 index 000000000..c0cace275 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/692 @@ -0,0 +1,2 @@ + +remove_fd_in_watch does not call g_source_unref diff --git a/results/classifier/accel-gemma3:12b/vmm/696530 b/results/classifier/accel-gemma3:12b/vmm/696530 new file mode 100644 index 000000000..9f3d14e02 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/696530 @@ -0,0 +1,8 @@ + +qemu-0.13.0-r2 special keys different when using -alt-grab + +I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f for full screen did not work for me with a windows guest. They work normally when omitting the -alt-grab startup parameter. + +After quite a long time, I found out that I have to add the shift key to the keys from the documentation when I use the -alt-grab option. + +Probably -ctrl-grab behaves similarly. It would be really nice to have this documented in the default documentation in the man page as has not been documented there yet. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/697197 b/results/classifier/accel-gemma3:12b/vmm/697197 new file mode 100644 index 000000000..c5732e024 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/697197 @@ -0,0 +1,27 @@ + +Empty password allows access to VNC in libvirt + +The help in the /etc/libvirt/qemu.conf states + +"To allow access without passwords, leave this commented out. An empty +string will still enable passwords, but be rejected by QEMU +effectively preventing any use of VNC." + +yet setting: + +vnc_password="" + +allows access to the vnc console without any password prompt just as if it is hashed out completely. + +ProblemType: Bug +DistroRelease: Ubuntu 10.10 +Package: libvirt-bin 0.8.3-1ubuntu14 +ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 +Uname: Linux 2.6.35-24-server x86_64 +Architecture: amd64 +Date: Tue Jan 4 12:18:35 2011 +InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) +ProcEnviron: + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: libvirt \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/708 b/results/classifier/accel-gemma3:12b/vmm/708 new file mode 100644 index 000000000..2f9426253 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/708 @@ -0,0 +1,11 @@ + +some TPM related files are missing in sysfs when enable passthrough TPM +Description of problem: +When enable passthrough TPM, there are some files in sysfs are missing, like description, uid file. +under the host linux, we have those file in it: +root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat description +TPM 2.0 Device +root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat uid +1 +Steps to reproduce: +after boot into system, check sysfs, there is no description and uid file in /sys/class/tpm/tpm0/device/firmware_node diff --git a/results/classifier/accel-gemma3:12b/vmm/709584 b/results/classifier/accel-gemma3:12b/vmm/709584 new file mode 100644 index 000000000..7df31991f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/709584 @@ -0,0 +1,20 @@ + +Fullscreen mode splits screen over monitor boundaries on dual-monitor system + +I originally reported this for the Android SDK emulator, which is built on QEMU: http://code.google.com/p/android/issues/detail?id=14336 + +Can confirm that this bug is present in stock QEMU shipped with Ubuntu 10.10: +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +Steps to reproduce: +- get a Linux machine with multiple-monitor setup (tested using NVidia proprietary driver on Ubuntu 10.10 x86_64, with two monitors side-by-side in 'TwinView' configuration) +- launch qemu +- hit ctrl+alt+f to go into fullscreen mode + +Expected behavior: +- emulator should take over one screen (either the first screen, largest screen, or screen the emulator is presently on) +- emulator's display should center or scale to fit within available area of the taken-over screen + +Actual behavior: +- emulator takes over both screens +- emulator's display is split over the boundary between the two screens \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/717929 b/results/classifier/accel-gemma3:12b/vmm/717929 new file mode 100644 index 000000000..41e7898c8 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/717929 @@ -0,0 +1,24 @@ + +Serial communication between VMs problematic + +Hello, + +I want to setup serial communication between VM hosts but I have found it quite difficult...: + +...because when trying unix sockets: + +- host A has serial device as unix socket (bind) +- host B has serial device as client of unix socket +- host A is down thus not unix socket does exist +- host B can't be started because cannot read the socket: + +error: Failed to start domain opd1s02 +error: internal error Process exited while reading console log output: char device redirected to /dev/pts/0 +connect(unix:/tmp/test.sock): Connection refused +chardev: opening backend "socket" failed + +Can that work like the cable is not plugged in? So host B can start and when the socket would exist it would connect to it? + +...and when using pty and host device combination one cannot predict pty device under /dev/pts, it would be nice if would be possible to define exact device name. + +Tested on Fedora 14. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/718 b/results/classifier/accel-gemma3:12b/vmm/718 new file mode 100644 index 000000000..ccd898f97 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/718 @@ -0,0 +1,7 @@ + +option to take screenshot with screendump as PNG +Additional information: +Libvirt already have preparation for PNG MIME type: https://github.com/libvirt/libvirt/blob/master/tools/virsh-domain.c#L5526 + + +Thanks diff --git a/results/classifier/accel-gemma3:12b/vmm/720657 b/results/classifier/accel-gemma3:12b/vmm/720657 new file mode 100644 index 000000000..7b904f0d5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/720657 @@ -0,0 +1,25 @@ + +SVM intercept for VINTR exits too early + +The following happens with QEMU-0.14-rc2. QEMU-0.13 did not have this problem. + +A guest operating system running inside an SVM VM contains the following code sequence: +c000002b: fb sti +c000002c: 0f 35 sysexit + +The following is a list of exits that occur at guest RIP 0xc000002c (other exits omitted for clarity): + +exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x1 int_control=0x1000000 inj=0x600000000 + +(exit due to physical interrupt, correctly reports STI blocking, entry does not inject anything) + +exit=0x60 int_shadow=0x1 int_control=0x1000000 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x1 int_control=0x1100100 inj=0x600000000 + +(exit due to physical interrupt, correctly reports STI blocking, entry pends a VINTR to cause a VM exit when interrupt window opens. VINTR is being intercepted by the hypervisor.) + +exit=0x64 int_shadow=0x0 int_control=0x1100100 inj=0x600000000 rip=0xc000002c +entry: int_shadow=0x0 int_control=0x1000000 inj=0x6800000a0 + +(exit due to VINTR. At this point STI blocking is still effective - though not reported. Actually, the VINTR exit should occur AFTER the SYSEXIT instruction, not after STI. Due to this bug, the hypervisor injects vector 0xa0 into an interrupt shadow, and things break). \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/721825 b/results/classifier/accel-gemma3:12b/vmm/721825 new file mode 100644 index 000000000..d30b66c3e --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/721825 @@ -0,0 +1,77 @@ + +VDI block driver bugs + +Chunqiang Tang reports the following issues with the VDI block driver, these are present in QEMU 0.14: + +"Bug 1. The most serious bug is caused by race condition in updating a new +bmap entry in memory and on disk. Considering the following operation +sequence. + O1: VM issues a write to sector X + O2: VDI allocates a new bmap entry and updates in-memory s->bmap + O3: VDI writes data to disk + O4: The disk I/O for writing sector X fails + O5: VDI reports error to VM and returns. + +Note that the bmap entry is updated in memory, but not persisted on disk. +Now consider another write that immediately follows: + P1: VM issues a write to sector X+1, which locates in the same block as +the previously used sector X. + P2: s->bmap already has one entry for the block, and hence VDI writes +data directly without persisting the new s->bmap entry on disk. + P3: The write disk I/O succeeds + P4: VDI report success to VM, but the bitmap entry is still not +persisted on disk. + +Now suppose the VM powers off gracefully (i.e., the QEMU process quits) +and reboots. The second write to sector X+1, which is reported as finished +successfully, is simply lost, because the corresponding in-memory s->bmap +entry is never persisted on disk. This is exactly what FVD's testing tool +discovers. After the block device is closed and then re-opened, disk +content verification fails. + +This is just one example of the problem. Race condition plus host crash +also causes problems. Consider another example below. + Q1: VM issues a write to sector X + Q2: VDI allocates a new bmap entry and updates in-memory s->bmap + Q3: VDI writes sector X to disk and waits for the callback + Q4: VM issues a write to another sector X+1, which is in the same block +as sector X. + Q5: VDI sees the bitmap entry in s->bmap is already allocated, and +writes sector X+1 to disk. + Q6: Write to sector X+1 finishes, and VDI's callback is invoked. + Q7: VDI acknowledges to the VM the completion of writing sector X+1 + Q8: After observing the completion of writing sector X+1, VM issues a +flush to ensure that sector X+1 is persisted on disk. + Q9: VDI finishes the flush and acknowledge the completion of the +operation. + Q10: ... (some other arbitrary operations, but the disk I/O for writing +sector X is still not finished....) + Q11: The host crashes + +Now the new bitmap entry is not persisted on disk, while both writing to +sector X+1 and the flush has been acknowledged as finished. Sector X+1 is +lost, which is a corruption. This problem exists even if it uses O_DSYNC. +The root cause of the problem is that, if a request updates in-memory +s->bmap, another request that sees this update assumes that the update is +already persisted on disk, which is not. + +Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are +several cases of the code below on failure handling path without setting +error return code, which mistakenly reports failure as success. This +mistake is caught by FVD when doing image content validation. + if (acb->hd_aiocb == NULL) { + /* missing ret = -EIO; */ + goto done; + } + +Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, +vdi_aio_cancel does not perform a complete clean up and there are several +related bugs. First, memory buffer is not freed, acb->orig_buf and +acb->block_buffer. Second, acb->bh is not cancelled. Third, +vdi_aio_setup() does not initialize acb->bh to NULL so that when a request +acb is cancelled and then later reused for another request, its acb->bh != +NULL and the new request fails in vdi_schedule_bh(). This is caught by +FVD's testing tool, when it observes that no I/O failure is injected but +VDI reports a failed I/O request, which indicates a bug in the driver." + +http://permalink.gmane.org/gmane.comp.emulators.qemu/94340 \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/722 b/results/classifier/accel-gemma3:12b/vmm/722 new file mode 100644 index 000000000..e24d215fa --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/722 @@ -0,0 +1,13 @@ + +Qemu slirp connectivity lost when host enters vpn(openvpn or wireguard) +Description of problem: +No connectivity after host enters a vpn, tested with valid openvpn +and wireguard. +Steps to reproduce: +1. Open the vpn. +2. Open a virtual machine using slirp +3. Ping 8.8.8.8(if you can...) +Additional information: +The bug is independent on the order of execution, if you start the vm +to see it works, and run the vpn script, the connectivity in the vm +will drop, and come back when the tunneled connection is over. diff --git a/results/classifier/accel-gemma3:12b/vmm/723 b/results/classifier/accel-gemma3:12b/vmm/723 new file mode 100644 index 000000000..b3f87156f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/723 @@ -0,0 +1,32 @@ + +multiple displays VGA + qxl forces Spice mouse-mode=server and breaks usb-tablet/seamless mode +Description of problem: +qxl causes a totally unexpected mouse conflict with the default VGA in OSX Catalina and newer guests using AppleVirtualGraphics.kext + +usb-tablet is unusable - only clicks are received +usb-mouse works but grabs focus +Steps to reproduce: +1. install and run OSX guest +2. connect to Spice port +3. can't move mouse if usb-tablet is used. usb-mouse pointer but is grabbed +4. removing qxl fixed the issue for me. Mouse is seamless/not grabbed now +5. added -spice agent-mouse=on just in case +Additional information: +qmp from broken shows mouse-mode server. Working guests show mouse-mode client + +``` +{ "execute": "query-spice" } +... "mouse-mode": "server"}} +``` +- spice works with multiple displays in OSX if both are VGA but I had the same focus problem, will need to recheck because Qemu 6.1 seems stuck on mouse-mode=server. + + +Working VGA +``` +/usr/bin/qemu-system-x86_64 -name macos-big-sur,process=macos-big-sur -pidfile macos-big-sur/macos-big-sur.pid -enable-kvm -machine q35,smm=off,vmport=off -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal\(c\)AppleComputerInc -no-hpet -global kvm-pit.lost_tick_policy=discard -cpu host,kvm=on,vendor=GenuineIntel,+hypervisor,+invtsc,+kvm_pv_eoi,+kvm_pv_unhalt -smp cores=2,threads=1,sockets=1 -m 8G -device virtio-balloon -smbios type=2,manufacturer="Wimpys World",product=Quickemu,version=2.3.1,serial=jvzclfjbeyq.pbz,location=wimpysworld.com,asset=macos-big-sur -device VGA,vgamem_mb=128 -display none -device usb-ehci,id=input -device usb-kbd,bus=input.0 -device usb-tablet,bus=input.0 -rtc base=localtime,clock=host,driftfix=slew -spice disable-ticketing=on,agent-mouse=on,port=5930 -device virtio-serial-pci -chardev socket,id=agent0,path=macos-big-sur/macos-big-sur-agent.sock,server=on,wait=off -device virtserialport,chardev=agent0,name=org.qemu.guest_agent.0 -device virtio-rng-pci,rng=rng0 -object rng-random,id=rng0,filename=/dev/urandom -chardev socket,id=monitor0,path=macos-big-sur/macos-big-sur-monitor.sock,server=on,wait=off -mon chardev=monitor0,id=monitor,mode=control -monitor none -serial mon:stdio -audiodev spice,id=audio0 -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -device virtio-net,netdev=nic -netdev user,hostname=macos-big-sur,hostfwd=tcp::22220-:22,id=nic -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=macos-big-sur/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=macos-big-sur/OVMF_VARS-1024x768.fd -device ahci,id=ahci -device ide-hd,bus=ahci.0,drive=BootLoader,bootindex=0 -drive id=BootLoader,if=none,format=qcow2,file=macos-big-sur/OpenCore.qcow2 -device virtio-blk-pci,drive=SystemDisk -drive id=SystemDisk,if=none,format=qcow2,file=macos-big-sur/disk.qcow2 -device qemu-xhci,id=spicepass -chardev spicevmc,id=usbredirchardev1,name=usbredir -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 -chardev spicevmc,id=usbredirchardev2,name=usbredir -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 -chardev spicevmc,id=usbredirchardev3,name=usbredir -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 -device usb-ccid -chardev spicevmc,id=ccid,name=smartcard -device ccid-card-passthru,chardev=ccid -device virtio-serial-pci -chardev spiceport,id=webdav0,name=org.spice-space.webdav.0 -device virtserialport,chardev=webdav0,name=org.spice-space.webdav.0 -fsdev local,id=fsdev0,path=/home/jmorrison/Public,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,mount_tag=Public-jmorrison +``` + +Broken usb-tablet qxl +``` +/usr/bin/qemu-system-x86_64 -name macos-big-sur,process=macos-big-sur -pidfile macos-big-sur/macos-big-sur.pid -enable-kvm -machine q35,smm=off,vmport=off -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal\(c\)AppleComputerInc -no-hpet -global kvm-pit.lost_tick_policy=discard -cpu host,kvm=on,vendor=GenuineIntel,+hypervisor,+invtsc,+kvm_pv_eoi,+kvm_pv_unhalt -smp cores=2,threads=1,sockets=1 -m 8G -device virtio-balloon -smbios type=2,manufacturer="Wimpys World",product=Quickemu,version=2.3.1,serial=jvzclfjbeyq.pbz,location=wimpysworld.com,asset=macos-big-sur -device qxl -display none -device usb-ehci,id=input -device usb-kbd,bus=input.0 -device usb-tablet,bus=input.0 -rtc base=localtime,clock=host,driftfix=slew -spice disable-ticketing=on,port=5930 -device virtio-serial-pci -chardev socket,id=agent0,path=macos-big-sur/macos-big-sur-agent.sock,server=on,wait=off -device virtserialport,chardev=agent0,name=org.qemu.guest_agent.0 -device virtio-rng-pci,rng=rng0 -object rng-random,id=rng0,filename=/dev/urandom -chardev socket,id=monitor0,path=macos-big-sur/macos-big-sur-monitor.sock,server=on,wait=off -mon chardev=monitor0,id=monitor,mode=control -monitor none -serial mon:stdio -audiodev spice,id=audio0 -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -device virtio-net,netdev=nic -netdev user,hostname=macos-big-sur,hostfwd=tcp::22220-:22,id=nic -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=macos-big-sur/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=macos-big-sur/OVMF_VARS-1024x768.fd -device ahci,id=ahci -device ide-hd,bus=ahci.0,drive=BootLoader,bootindex=0 -drive id=BootLoader,if=none,format=qcow2,file=macos-big-sur/OpenCore.qcow2 -device virtio-blk-pci,drive=SystemDisk -drive id=SystemDisk,if=none,format=qcow2,file=macos-big-sur/disk.qcow2 -device qemu-xhci,id=spicepass -chardev spicevmc,id=usbredirchardev1,name=usbredir -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 -chardev spicevmc,id=usbredirchardev2,name=usbredir -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 -chardev spicevmc,id=usbredirchardev3,name=usbredir -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 -device usb-ccid -chardev spicevmc,id=ccid,name=smartcard -device ccid-card-passthru,chardev=ccid -device virtio-serial-pci -chardev spiceport,id=webdav0,name=org.spice-space.webdav.0 -device virtserialport,chardev=webdav0,name=org.spice-space.webdav.0 -fsdev local,id=fsdev0,path=/home/jmorrison/Public,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,mount_tag=Public-jmorrison +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/727 b/results/classifier/accel-gemma3:12b/vmm/727 new file mode 100644 index 000000000..d4846b107 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/727 @@ -0,0 +1,157 @@ + +VHDX is corrupted on expansion +Description of problem: +Fresh VHDX corrupts with data loss upon copying data into it. +Steps to reproduce: +1. Create new dynamic vhdx file of about 93Gib (unexpanded, starting size is small ~205Mib, freshly created and NTFS formatted in windows.) +2. Connect drive using qemu-nbd to /dev/nbd0 +3. Ensure partition using gdisk +4. format partition with ntfs/ExFAT volume +5. mount volume +6. copy/rsync data of about 85Gib of data into the mounted volume +7. unmount volume +8. disconnect /dev/nbd0 +9. reconnect /dev/nbd0 +10. attempt mount, sometimes mount may fail if corrupted +11. If mount succeeds, verify data/all-files using some method like sha256sum. Some data is likely to fail + +Given the amount of data I am rsync-ing into the volume, there is very high chance of corruption. + +The corruption is not apparent until **disconnection and reconnection** of virtual-disk. Simply unmounting and remounting without disconnecting is unlikely to cause one to suspect corruption. + +If the expanded corrupted volume is again disconnected, reconnected, reformatted and data is again re-copied onto it, then the volume is less likely to experience a corruption, perhaps because new block allocation is not required. + +Errors vary and include: +- sometimes mount fails +- sometimes ls -l output is garbled +- sometimes one cannot cd into a directory +- several consecutive errors in shasum256 start midway through the file-list processing. Error is shown as if rsync failed and files do not exist. + ``` + sha256sum: ./201207/IMG_2406.JPG: No such file or directory + ./201207/IMG_2406.JPG: FAILED open or read + ``` +- Doing chdsk on windows may just create FOUND.000/FILE0000.CHK files. +Additional information: +See comment https://gitlab.com/qemu-project/qemu/-/issues/136#note_731044761 from where this all began. Some summary included here. + +``` +[root@sirius a16]# uname -a +Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux + +[root@sirius ~]# qemu-system-x86_64 --version +QEMU emulator version 6.1.0 (qemu-6.1.0-10.fc35) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +[root@sirius ~]# cat /etc/mtab | grep -E "a16|a17" | grep ntfs3 +/dev/sda16 /mnt/a16 ExFAT rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0 +/dev/sda17 /mnt/a17 ntfs3 rw,relatime,uid=0,gid=0,iocharset=utf8 0 0 + +[root@sirius ~]# uname -a # self-built rpmbuild kernel from fedora rawhide kernel-src rpm +Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux +``` + +Test/Activity being done: About 85Gib of data is copied onto a size 93Gib VHDX on host-FS ntfs3 with guest-FS ntfs3. +``` +Prefer windows method: Inside windows-10, using powershell command New-VHD, one may a 93Gib VHDX + New-VHD -Path I:\gkpics01.vhdx -SizeBytes 99723771904 -Dynamic + Then attach disk and format volume inside to ntfs. +or Alternatively, Linux method (less preferred) + qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 + qemu-img create -f vhdx -o subformat=dynamic /mnt/a16/gkpics01.vhdx 99723771904 +: +sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx +: +create appropriate partitions on /dev/nbd0 if not already partitioned +gdisk /dev/nbd0 +: +format volume with filesystem ntfs, or ext4 etc if not already formatted +mkfs -t ntfs -Q -L fs_gkpics01 /dev/nbd0p2 +: +mount partition +sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1 +: +do copy/rsync etc +( fl="photos001" ; src="/mnt/c13" ; dst="/mnt/t1" ; cd "$src" ;rsync -avH "$fl" "$dst" ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" ) +: +sync ; sleep 1 ; umount /mnt/t1 +: +sync ; sleep 1 ; blockdev --flushbufs /dev/nbd0 ; sleep 2 ; qemu-nbd -d /dev/nbd0 ; sleep 1 ; sync +: +sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx +: +sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1 +: +do ls-l/verify/sha256sum-c etc +( fl="photos001" ; rtpt="/mnt/t1" ; cd "${rtpt}/${fl}" ; sdate=`date` ; echo "$sdate" ; sha256sum -c "$rtpt/$fl/find.CHECKSUM" --quiet ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "checksum $src/$fl" ) +``` + +In the below list detailing under what circumstance corruption occurs + +- Format: kernel-version/ disk-attaching-sw/ hostFS/ VDISK/ guestFS with any parameters in parenthesis. +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ext4 +- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=direct)/ntfs3/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=libvirt-7.6.0-3)/ntfs3/VHDX/ntfs3 +- Corruption does happen on host-FS **ExFAT too** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.0.0-10/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX/ntfs3g-fuseblk +- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX(created by qemu-img)/ntfs3g-fuseblk + ``` Failed to mount '/dev/nbd0p2': Input/output error NTFS is either inconsistent, or there is a hardware fault,``` +- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ext4 +- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ntfs3g-fuseblk +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=threads)/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=io_uring)/ntfs3 +- VHDX fixed disk grows in size. Filed as different bug: https://gitlab.com/qemu-project/qemu/-/issues/806 + - Corruption **does happen** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(fixed)/ntfs3 + A fixed vhdx disk should not grow in size. It is as if the blocks are added to a vhdx-journal instead of overwriting preallocated blocks. +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ext4/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-6.2.0-rc1**/ExFAT/VHDX/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VMDK**(v4,monolithicSparse)/ntfs3 +- Corruption does not happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/VMDK(compat6,monolithicSparse)/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VDI**/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VPC**(dynamic)/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-5.2.0-8**/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-4.2.1-1**/ExFAT/VHDX/ntfs3 +- Corruption does happen with vhdx-file is on 2Tb NTFS 1Tb partition of **external USB HDD** 2Tb, with kernel-5.15.2-200/qemu-6.2.0-rc1/ntfs3/VHDX/ntfs3 +- Corruption does happen when using src is on ntfs3 partition on external USB drive, which is **generated synthetic data (sgdata)** sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX/ntfs3 +- Corruption does happen when starting with qemu-img created vhdx image with sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX(created by qemu-img)/ext4 superblock mount fail +- Corruption does happen older fc34-kernel on Fedora-35, sgdata/kernel-5.13.19-200/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , different, fewer files 3 small files affected +- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , fewer files, different, but same as above 3 small files affected, +- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ext4 +- Corruption does happen with self-built 5.10 LTS kernel on Fedora-35, sgdata/kernel-5.10.90-200/qemu-6.2.0-1/ExFAT/VHDX/ext4 (sgdata accessed using ntfs-fuseblk) +- As the host kernel invoking qemu-nbd, these kernels showed less errors than if they were run inside a VM as a guest. If run as a guest VM, These kernels, 5.15.4 and above, may also have kernel bugs https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 resulting in additional compounded errors in the failure test results, even in raw-img and qcow2(fixed). + - Corruption does happen with sgdata/kernel-5.15.4-201/qemu-6.2.0-rc1/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does happen with sgdata/kernel-5.15.4-201/**qemu-6.2.0-rc2**/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does not happen with synthetic-data sgdata/kernel-5.15.4-201/qemu-6.2.0-rc2/ExFAT/VMDK(created by qemu-img)/ext4 + - Corruption does happen with sgdata/kernel-5.15.5-200/qemu-6.2.0-rc2/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/vmdk/ntfs3 + - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin/ExFAT/vmdk-nbd-vddkplugin/ntfs3 + - Corruption does happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3 + - Corruption does happen with sgdata/kernel-5.15.6-200 to kernel-5.15.13-200 /qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3 +- On Windows-10, these tests may possibly be different bug. Also causes system-wide DiskIO stuck in addition to corruption https://github.com/cloudbase/wnbd/issues/63 + - Corruption does happen with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/VHDX/NTFS + - Corruption **does happen** with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/**qcow2**/NTFS +- Possibly different bug, on Windows-10, corruption of virtual-disk from inside VM, no nbd . Maybe https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 + - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/VHDX/ntfs3 + - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/**qcow2**/ext4 +- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**qcow2(dyn)**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata +- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/qcow2(dyn)/ntfs3 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**VHDX**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/**Rocky-8.5-Workstation-20211114.iso**/**kernel-4.18.0-348.el8.0.2.x86_64**/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata + +ExFAT filesystem was considered because it does not have concept of sparse files eliminating that factor from troubleshooting. Furthermore, it may be incorrect to suspect NTFS3, ExFAT or NTFS3g-fuseblk only because they are new/recently mainstreamed filesystems, as there aren't any intense/complex filesystem operations. The filesystem is experiencing only though-put and files are simply copied into it without further operations. Furthermore, ext4 also experiences corruption if on VHDX. + +It just seems to me the VHDX support implementation has bugs, corrupts and hence is not reliable. + +The qemu test-suite needs test-cases added for testing for vhdx-stress and vhdx-throughput . + +More troubleshooting test results are summarized in https://gitlab.com/qemu-project/qemu/-/issues/727#note_745711084 + +Chief suspect files +- ~~kernel: nbd: [drivers/block/nbd.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/nbd.c)~~ can be made to happen via VM +- ~~kernel: ntfs3~~ no ntfs3 partition required +- ~~kernel 5.x series~~ bug exists in 4.18.0.348 +- ~~qemu: block~~ doesn't happen to other virtual-disk formats (raw,qcow2) +- qemu/VM : seems to happen only when using qemu-nbd or inside qemu-VM +- qemu: [block/vhdx.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.c) , [block/vhdx_log.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-log.c) , [block/vhdx-endian.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-endian.c) , [block/vhdx.h](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.h), diff --git a/results/classifier/accel-gemma3:12b/vmm/728 b/results/classifier/accel-gemma3:12b/vmm/728 new file mode 100644 index 000000000..df8a39ce2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/728 @@ -0,0 +1,17 @@ + +Catch up to latest VHDX v2(=0x01) rev-7.0 specification +Additional information: +Below issues need to be addressed before or during the tackling of this issue. +- ~#727 VHDX is corrupted on expansion.~ +- #136 windows qemu-img create vpc/vhdx error due to sparse files +- #1605 On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c +- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts +- +This VHDX support applies to qemu build on any architecture, not just the windows-build. + +It is very likely, that the native hypervisor on windows WHPX will be the main hypervisor displacing haxm/vbox etc. VHDX, if it works, seems to be the virtual-disk format that is ideal +- for Linux/windows dual-boot machines, +- for clusters with Linux/windows servers sharing images from a network-storage +- for WSL2/Hyper-V + +Following a similar line of thought, NTFS/ExFat may be ideal for sharing data/images between Linux and Windows. So the storing, modification and drive attachment of VHDX files on these filesystems need to be just as well-tested as native Linux filesystems. As their driver are internal-kernel-drivers and not fuse/dokan-drivers, on both operating-systems, they are also performant. diff --git a/results/classifier/accel-gemma3:12b/vmm/731 b/results/classifier/accel-gemma3:12b/vmm/731 new file mode 100644 index 000000000..2eaf7fe17 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/731 @@ -0,0 +1,22 @@ + +Display resolution fixed by 800x600 with latest VirtIO drivers and guest additions +Description of problem: +Display resolution can't be changed to anything else than 800x600. +Steps to reproduce: +1. Install qemu/kvm +2. Create virtual machine +3. Setup Windows 10 +4. Install VirtIO-Drivers +5. Install guest-agent +6. Install qxl-drivers + +Steps 5 and 6 enable use of QXL-Display, but do not lead to allow for higher display resolutions than before. +Additional information: + + + +Screen resolution is fixed by 800x600. +Driver is installed, but seems to have a problem (Attention sign. Warning, Error: digital signatur could not be checked -- at least there is no how to to make the existing signature work). +Latest available VirtIO-drivers where used as available from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso + +Older available drivers did not work too as expected. Same problem. Could not check older Windows 10 versions, because of lack of older install media. diff --git a/results/classifier/accel-gemma3:12b/vmm/743 b/results/classifier/accel-gemma3:12b/vmm/743 new file mode 100644 index 000000000..2b947aa83 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/743 @@ -0,0 +1,12 @@ + +aarch64: Number of SMP CPUS exceeds max CPUs supported by machine (10 > 8) for M1 Pro/Max +Description of problem: +Trying to launch QEMU with more than 8 cores gives the following error: + +`qemu-system-aarch64: Number of SMP CPUs requested (10) exceeds max CPUs supported by machine 'mach-virt' (8)` + +Apple M1 Pro can have up to 10 cores while M1 Max only has 10 cores. +Steps to reproduce: +1. Install QEMU via homebrew (or MacPorts or from source) +2. Run `qemu-system-aarch64 -machine virt,highmem=off -accel hvf -cpu cortex-a72 -smp 10` +3. Get error, QEMU doesn't start diff --git a/results/classifier/accel-gemma3:12b/vmm/747 b/results/classifier/accel-gemma3:12b/vmm/747 new file mode 100644 index 000000000..a394c1f7c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/747 @@ -0,0 +1,31 @@ + +hvf-accelerated aarch64 hangs when switching to big endian mode +Description of problem: +Trying to boot a big endian Linux kernel using the above command line on an M1 Mac Mini just hangs, there is not a single output. However, by replacing `hvf` with `tcg`, the kernel boots up fine. The kernel also starts if I use KVM acceleration on a Linux host system. +Steps to reproduce: +1. Build a Linux kernel for big endian arm64 +2. Try to boot it with -accel hvf on an M1 Mac +3. Observe a lot of nothing happening :-) +Additional information: +Sample run, TCG vs HVF +``` +mikan:/tmp% qemu-system-aarch64 -accel tcg -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be |& head -16 +[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083] +[ 0.000000] Linux version 5.10.76-gentoo-r1-arm64 (root@localhost) (aarch64-unknown-linux-gnu-gcc (Gentoo 11.2.0 p1) 11.2.0, GNU ld (Gentoo 2.37_p1 p0) 2.37) #1 SMP Sun Nov 21 16:30:21 -00 2021 +[ 0.000000] Machine model: linux,dummy-virt +[ 0.000000] NUMA: No NUMA configuration found +[ 0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] NUMA: NODE_DATA [mem 0x47f65300-0x47f76fff] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] DMA32 empty +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x0000000047ffffff] +[ 0.000000] psci: probing for conduit method from DT. +[ 0.000000] psci: PSCIv0.2 detected in firmware. +mikan:/tmp% qemu-system-aarch64 -accel hvf -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be +``` +(followed by tumbleweeds) diff --git a/results/classifier/accel-gemma3:12b/vmm/759 b/results/classifier/accel-gemma3:12b/vmm/759 new file mode 100644 index 000000000..351929e2b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/759 @@ -0,0 +1,13 @@ + +Copy&Paste does not work on VNC +Description of problem: +Cannot copy&paste between host and guest when vnc is used (gtk works fine). +Steps to reproduce: +1. Build qemu 6.2-rc2 using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek +``` +2. Run the above qemu command using vnc server. Connect to the VM desktop using `vncviewer :5900` where vncviewer is downloaded from [here](https://www.realvnc.com/en/connect/download/viewer/). +3. Try to copy and paste something in the terminal between host and guest. It doesn't work. +Additional information: +I'm following [this article](https://www.kraxel.org/blog/2021/05/qemu-cut-paste/) which says copy&paste is supported on vnc. diff --git a/results/classifier/accel-gemma3:12b/vmm/76 b/results/classifier/accel-gemma3:12b/vmm/76 new file mode 100644 index 000000000..0c2f5b497 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/76 @@ -0,0 +1,2 @@ + +Mouse cursor sometimes can't pass the invisible border on the right side of the screen diff --git a/results/classifier/accel-gemma3:12b/vmm/761469 b/results/classifier/accel-gemma3:12b/vmm/761469 new file mode 100644 index 000000000..8abf063c6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/761469 @@ -0,0 +1,12 @@ + +multicast VPN breaks IPv6 Duplicate Address Detection + +The multicast VPN facility in Qemu uses Multicast Loopback to make sure that other Qemu processes on the Host server receive the transmission. The side effect of this is that the process sending the packet also gets the packet back on its receive channel and currently this is not filtered but passed directly to the Virtual Machine. + +You can see this effect by running tcpdump in the virtual machine. Every packet sent appears to be duplicated. + +For IPv4 it doesn't appear to cause much of a problem, however with IPv6 the duplicate neighbor solicitation packet is precisely what the system uses to detect duplicate addresses. So IPv6 addresses fail to establish. + +If you run 'ip addr' on a virtual Linux machine with IPv6 enabled you will see 'dadfailed' next to the link local address. 'ping6' will then not work. + +Checked against 0.12.1. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/761471 b/results/classifier/accel-gemma3:12b/vmm/761471 new file mode 100644 index 000000000..aa0e11d01 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/761471 @@ -0,0 +1,6 @@ + +Multicast VPN TTL hardcoded at 1 + +The multicast VPN opens sockets with the default TTL of 1 and there doesn't appear to be an option anywhere that will allow you to increase that. + +This limits the usability of the VPN to the local network where the host server lives. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/764 b/results/classifier/accel-gemma3:12b/vmm/764 new file mode 100644 index 000000000..b4ba66722 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/764 @@ -0,0 +1,46 @@ + +qemu-system-x86 crash (reason: use after free in socket_reconnect_timeout when reconnecting vhost-user dev) +Description of problem: +(gdb) bt<br/> +#0 0x00007f205976b78b in raise () from /usr/lib64/libc.so.6<br/> +#1 0x00007f205976cab1 in abort () from /usr/lib64/libc.so.6<br/> +#2 0x00007f205976404a in ?? () from /usr/lib64/libc.so.6<br/> +#3 0x00007f20597640c2 in __assert_fail () from /usr/lib64/libc.so.6<br/> +#4 0x00007f20594ea556 in **qemu_mutex_lock_impl**(mutex=<optimized out>, file=<optimized out>, line=<optimized out>)<br/> +#5 0x00007f205957a4ef in **socket_reconnect_timeout** (opaque=<optimized out>)<br/> +#6 0x00007f205993b68d in ?? () from /usr/lib64/libglib-2.0.so.0<br/> +#7 0x00007f205993aba4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0<br/> +#8 0x00007f20594e5d49 in glib_pollfds_poll () at /usr/src/debug/qemu-4.1.0-666.x86_64/util/main-loop.c:218<br/> +#9 0x00007f20594e5dc2 in os_host_main_loop_wait (timeout=<optimized out>)<br/> +#10 0x00007f20594e5f5d in main_loop_wait (nonblocking=nonblocking@entry=0)<br/> +... ...<br/> +#14 0x0000560919e13180 in main (argc=80, argv=0x7ffebc1d0598, envp=0x7ffebc1d0820)<br/> + +at the moment, chr had be free by hot unplug vhost-user dev<br/> + +I think the bug cause reason as following:<br/> +1. when vhost-user dev is connecting state, io-task-worker thread will try call tcp_chr_connect_client_async <br/> + again and again to reconnect.<br/> +2. if reconnect fail, io-task-worker thread will switch to main-thread to handle error, and main-thread will <br/> +call qemu_chr_socket_restart_timer again to reconnect again. <br/> + +3. But, if a hot unplug operation insert to main-thread before io-task-worker switch to main-thread,<br/> + the qemu_chr_socket_restart_timer->socket_reconnect_timeout process will use the released chardev and <br/> + trigger qemu crash + +in short, the primary cause of this bug is io-task-worker reconnect process and <br/> +main-thread hot unplug vhost-user-dev process in a race.<br/> +Steps to reproduce: +1. in qio_task_thread_worker func, add sleep in the following position: <br/> +  task->thread->completion = g_idle_source_new(); <br/> +  g_source_set_callback(task->thread->completion,<br/> + qio_task_thread_result, task, NULL);<br/> +  **sleep(8);**<br/> +  g_source_attach(task->thread->completion,<br/> + task->thread->context);<br/> +  g_source_unref(task->thread->completion); <br/> +2. kill spdk proces or dpdk process, qemu will reconnect to the disconnected vhost-user dev of spdk or dpdk <br/> +3. hot unplug the disconnected vhost-user dev when reconnect logic goto upper sleep position <br/> +4. qemu_chr_socket_restart_timer will use the chr after free, and trigger qemu crash +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/779 b/results/classifier/accel-gemma3:12b/vmm/779 new file mode 100644 index 000000000..d6652bd70 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/779 @@ -0,0 +1,14 @@ + +VNC server not work +Description of problem: +I've created a sandbox guest with kata containers. The VM started successfully, but vnc server not listen unix socket. + +`root@bootstrap02:~# netstat -anp | grep 1989153` +`unix 3 [ ] STREAM CONNECTED 369610592 1989153/qemu-system /run/vc/vm/bash/qmp.sock` +`root@bootstrap02:~# lsof -p 1989153 | grep unix` +`qemu-syst 1989153 root 108u unix 0xffff912740d3b800 0t0 369610592 /run/vc/vm/bash/qmp.sock type=STREAM` +Steps to reproduce: +1.Create Linux sandbox guest VM +2.connect vnc server +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/78 b/results/classifier/accel-gemma3:12b/vmm/78 new file mode 100644 index 000000000..c126a0d26 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/78 @@ -0,0 +1,2 @@ + +msmouse serial mouse emulation broken? No id byte sent on reset diff --git a/results/classifier/accel-gemma3:12b/vmm/780 b/results/classifier/accel-gemma3:12b/vmm/780 new file mode 100644 index 000000000..16d609743 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/780 @@ -0,0 +1,55 @@ + +qemu-system-x86_64: qemu dead-lock when mirror job exit and vm stop in a race +Description of problem: +machine under continuous pressure, at the end of the migration phase. +Libvirtd construction exception at the same time. +In mirror_run, mirror_write_complete set s->ret to negative value and exit mirror_run; Job_co_entry throws the bh of job_exit into the main thread; + +While the live_migration thread gets the qemu_global_mutex, and set to main thread by blk_set_aio_context; when it just polles the bh of job_exit, and run to bdrv_flush. So there need the main thread to process bdrv_flush_co_entry, then we can exit bdrv_flush. +If the main thread is waiting the qemu_mutex_lock_iothread_impl, bdrv_flush_co_entry cannot be executed, and the Live_migration thread cannot exit to release qemu_global_mutex, resulting in deadlock +Steps to reproduce: +1.migrate the machine and let machine under continuous pressure; +2.gdb to qemu and make break point to virtio_blk_data_plane_stop; +3.when hit virtio_blk_data_plane_stop, kill libvirtd; +4.let live_migration thread to poll job_exit +Additional information: +``` +#0 0x00007f8f662d12f2 in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:112 +#1 0x00007f8f662d58ae in aio_poll (ctx=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#2 0x00007f8f6530bcca in bdrv_flush (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block/io.c:2778 +#3 0x00007f8f65345143 in bdrv_close (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block.c:4073 +#4 0x00007f8f65345373 in bdrv_delete (bs=0x5580c5857b30) at /usr/src/qemu/block.c:4335 +#5 0x00007f8f65345405 in bdrv_unref (bs=<optimized out>) at /usr/src/qemu/block.c:5676 +#6 0x00007f8f65344d95 in bdrv_root_unref_child (child=<optimized out>) at /usr/src/qemu/block.c:2516 +#7 0x00007f8f65353f56 in block_job_remove_all_bdrv (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/blockjob.c:203 +#8 0x00007f8f65317b87 in mirror_exit_common (job=0x5580c6d55cc0) at /usr/src/qemu/block/mirror.c:776 +#9 0x00007f8f65317cc8 in mirror_abort (job=<optimized out>) at /usr/src/qemu/block/mirror.c:804 +#10 0x00007f8f6632737b in job_finalize_single (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/job.c:680 +#11 0x00007f8f66327d70 in job_completed_txn_abort (job=<optimized out>) at /usr/src/qemu/job.c:758 +#12 0x00007f8f66328018 in job_exit (opaque=0x5580c6d55cc0) at /usr/src/qemu/job.c:873 +#13 0x00007f8f662d130f in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:118 +#14 0x00007f8f662d5716 in aio_poll (ctx=ctx@entry=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#15 0x00007f8f662e6b4d in aio_wait_bh_oneshot (ctx=0x5580c53a5c60, cb=<optimized out>, opaque=<optimized out>) at /usr/src/qemu/util/aio-wait.c:71 +#16 0x00007f8f65340978 in bdrv_attach_aio_context (bs=bs@entry=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60) at /usr/src/qemu/block.c:5985 +#17 0x00007f8f65345fd5 in bdrv_set_aio_context_ignore (bs=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6050 +#18 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=0x5580c5857b30, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#19 0x00007f8f65353bd4 in child_job_set_aio_ctx (c=<optimized out>, ctx=0x5580c53a5c60, ignore=0x7f8eb8ff8c20) at /usr/src/qemu/blockjob.c:172 +#20 0x00007f8f6534604b in bdrv_set_aio_context_ignore (bs=0x5580c53c46c0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6040 +#21 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=bs@entry=0x5580c5978290, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#22 0x00007f8f653462b8 in bdrv_child_try_set_aio_context (bs=bs@entry=0x5580c5978290, ctx=ctx@entry=0x5580c53a5c60, ignore_child=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block.c:6145 +#23 0x00007f8f653029aa in blk_do_set_aio_context (blk=0x5580c53c42b0, new_context=0x5580c53a5c60, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1948 +#24 0x00007f8f65304b0d in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1980 +#25 0x00007f8f64f07976 in virtio_blk_data_plane_stop (vdev=0x5580c6d8a510) at /usr/src/qemu/hw/block/dataplane/virtio-blk.c:305 +#26 0x00007f8f64f7be83 in virtio_bus_stop_ioeventfd (bus=0x5580c6d8a498) at /usr/src/qemu/hw/virtio/virtio-bus.c:247 +#27 0x00007f8f64f77e8b in virtio_vmstate_change (opaque=0x5580c6d8a510, running=0, state=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/hw/virtio/virtio.c:2423 +#28 0x00007f8f663563f5 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/huawei/microvm/microvm-platform.c:196 +#29 0x00007f8f66335af9 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=send_stop@entry=true) at /usr/src/qemu/cpus.c:1130 +#30 0x00007f8f66335dd1 in vm_stop (state=<optimized out>) at /usr/src/qemu/cpus.c:2207 +#31 0x00007f8f66335f7e in vm_stop_force_state (state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/cpus.c:2267 +#32 0x00007f8f65197cfc in migration_try_vm_stop_and_save_concurrent (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:2976 +#33 0x00007f8f6519c627 in migration_completion (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3039 +#34 0x00007f8f6519cc8b in migration_iteration_run (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3571 +#35 0x00007f8f6519d190 in migration_thread (opaque=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3801 +#36 0x00007f8f662d82e0 in qemu_thread_start (args=0x5580c57d0300) at /usr/src/qemu/util/qemu-thread-posix.c:519 +#37 0x00007f8f6648bf3b in start_thread (arg=0x7f8eb8ff9700) at pthread_create.c:486 +``` diff --git a/results/classifier/accel-gemma3:12b/vmm/784977 b/results/classifier/accel-gemma3:12b/vmm/784977 new file mode 100644 index 000000000..5829348e0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/784977 @@ -0,0 +1,27 @@ + +qemu-img convert fails to convert, generates a 512byte file output + +I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to convert to VirtualBox .vdi format using qemu, the first stage of extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just generates a 512byte file: + +{quote} +# Disk DescriptorFile +version=1 +CID=36be9761 +parentCID=ffffffff +createType="twoGbMaxExtentSparse" + +# Extent description +RW 4192256 SPARSE "Ubuntu-s001.vmdk" +RW 4192256 SPARSE "Ubuntu-s002.vmdk" +RW 4192256 SPARSE "Ubuntu-s003.vmdk" +RW 4192256 SPARSE "Ubuntu-s004.vmdk" +RW 4192256 SPARSE "Ubuntu-s005.vmdk" +RW 4192256 SPARSE "Ubuntu-s006.vmdk" +RW 4192256 SPARSE "Ubuntu-s007.vmdk" +RW 4192256 SPARSE "Ubuntu-s008.vmdk" +RW 4192256 SPARSE "Ubuntu-s009.vmdk" +RW 4192256 SPARSE "Ubuntu-s010.vmdk" +RW 20480 SPARSE "Ubunt +{quote} + +No stack trace or other output was found. Anything I can add (other than the 20G VM image to reproduce and I'll be happy to provide) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/786440 b/results/classifier/accel-gemma3:12b/vmm/786440 new file mode 100644 index 000000000..6030034e2 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/786440 @@ -0,0 +1,4 @@ + +qcow2 double free + +version 0.14.1 when using qcow2 images, after some time, glibc detects a double free or corruption. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/788701 b/results/classifier/accel-gemma3:12b/vmm/788701 new file mode 100644 index 000000000..c0742a3dc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/788701 @@ -0,0 +1,11 @@ + +qemu-user fails to run rpcgen (i386, x86_64) + +Confirmed on qemu current development tree (git commit aa29141). While trying to run eglibc's rpcgen from native system by qemu-user, I get an error: + +qemu-x86_64 /usr/bin/rpcgen -c /dev/null +fork: Invalid argument + +I am running a Debian Wheezy system and rpcgen comes from libc-dev-bin. Just in case I am attaching my rpcgen binaries from i386 and x86_64 systems. + +Very similar problem was mentioned on the QEMU forum on February 2007, so I guess it might be a known issue. Nevertheless, I was unable to find any information about bug reports, fixes nor workarounds for it so I'm reporting it here. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/789652 b/results/classifier/accel-gemma3:12b/vmm/789652 new file mode 100644 index 000000000..cd75a409a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/789652 @@ -0,0 +1,14 @@ + +Cannot confirm email address on QEMU Wiki + +Cannot confirm email address on QEMU Wiki + +http://wiki.qemu.org/Special:ConfirmEmail + +--- + +Confirm e-mail address + +QEMU could not send your confirmation mail. Please check your e-mail address for invalid characters. + +Mailer returned: mailer error \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/791 b/results/classifier/accel-gemma3:12b/vmm/791 new file mode 100644 index 000000000..b1f38eed5 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/791 @@ -0,0 +1,2 @@ + +unable to execute QEMU command - SGX VM using libvirtd diff --git a/results/classifier/accel-gemma3:12b/vmm/797 b/results/classifier/accel-gemma3:12b/vmm/797 new file mode 100644 index 000000000..9f104e615 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/797 @@ -0,0 +1,10 @@ + +ARM64 hvf fails to boot Windows 11 on 6.2.0 +Description of problem: +On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner"). +Steps to reproduce: +1. `brew install qemu` +2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64 +3. Run command from above. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/798 b/results/classifier/accel-gemma3:12b/vmm/798 new file mode 100644 index 000000000..8da1f9440 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/798 @@ -0,0 +1,16 @@ + +The sandbox option elevelateprivileges=deny does not work with -daemonize +Description of problem: +qemu will not launch if `-sandbox on,elevateprivileges=deny` and `-daemonize` are set at the same time. +Steps to reproduce: +``` +qemu-system-x86_64 -sandbox on,elevateprivileges=deny -nodefaults -daemonize +``` +-> fails to launch + +``` +qemu-system-x86_64 -sandbox on -nodefaults -daemonize +``` +-> runs normally +Additional information: +[journal.txt](/uploads/c0e2a973e749011c3b1ac2158420a4e8/journal.txt) diff --git a/results/classifier/accel-gemma3:12b/vmm/802 b/results/classifier/accel-gemma3:12b/vmm/802 new file mode 100644 index 000000000..dc9179d65 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/802 @@ -0,0 +1,27 @@ + +Devices created using '-device' JSON syntax don't emit DEVICE_DELETED when unplugged +Description of problem: +Run the following sequence: + +``` + $ ./qemu-system-x86_64 -qmp stdio \ + -device '{"driver": "virtio-mouse-pci", "id": "dev0"}' \ + -device virtio-mouse-pci,id=dev1 +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 6}, "package": "v6.2.0-105-g7494244ffc-dirty"}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev0"} } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev1"} } +{"return": {}} +{ "execute": "system_reset" } +{"return": {}} +{"timestamp": {"seconds": 1641385071, "microseconds": 120178}, "event": "RESET", "data": {"guest": false, "reason": "host-qmp-system-reset"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121431}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev1/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121684}, "event": "DEVICE_DELETED", "data": {"device": "dev1", "path": "/machine/peripheral/dev1"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 122297}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev0/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 198581}, "event": "RESET", "data": {"guest": true, "reason": "guest-reset"}} + + ``` + +Notice the lack of a "DEVICE_DELETED" event with path "/machine/peripheral/dev0" - the device created with JSON syntax diff --git a/results/classifier/accel-gemma3:12b/vmm/806656 b/results/classifier/accel-gemma3:12b/vmm/806656 new file mode 100644 index 000000000..d69e144c3 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/806656 @@ -0,0 +1,8 @@ + +Tight PNG VNC encoding is sent even when --disable-vnc-png is set + +This bug exists in 0.14.1 and also in 9312805d33e8b (Jun 17, 2011) in the master git repo. + +The "Tight PNG" encoding is a derivative of the "Tight" encoding that replaces zlib encoded rects with PNG encoded data instead. However, when the "Tight PNG" encoding is disabled (--disable-vnc-png), the server will send frame buffer updates that are marked as "Tight PNG" but in fact contain zlib encoded regions (i.e. it's really "tight" protocol). + +The "Tight PNG" encoding should only be used when --enable-vnc-png is set. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/807 b/results/classifier/accel-gemma3:12b/vmm/807 new file mode 100644 index 000000000..79eef675b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/807 @@ -0,0 +1,19 @@ + +TigerVNC client to built-in VNC server causes VM to crash/freeze +Description of problem: +Connecting to the built-in VNC server via TigerVNC upon disconnect the whole VM process freezes/crashes. The process continues to exist but does not respond to any network connection and the monitor socket is dead too. Killing it with TERM doesn't work. + +Using tigervnc-viewer 1.10.1+dfsg-3 (Ubuntu 20.04) with default options like `vncviwer localhost:0` +Steps to reproduce: +* `qemu-system-x86_64 -vnc 127.0.0.1:0` + * Connect to built-in VNC server via TigerVNC + * Keep the VNC connection open and wait some period of time (usually 5-10 minutes is enough though sometimes hours) then disconnect/reconnect VNC. If the reconnect succeeds then wait again for a period of time then disconnect and try again until failure. Often just connecting and disconnecting to the VNC once is enough to make the VM eventually crash/freeze even if running only in the background but this is less reproducible. + * Observe VM is no longer responsive to anything + +If TigerVNC is never connected/disconnected from the VM then this doesn't happen. +Additional information: +Note due to the nature of this issue it might be hard to reproduce for unknown reasons. The VM always eventually freezes though. The qemu process has no output when it freezes. + +As far as I can tell connecting to the built-in VNC server via `gvncviwer` seems to be OK and doesn't cause an issue (?). I'm not sure about other VNC clients (eg. TurboVNC). + +I am connecting to the VNC server from a completely different machine than the host via SSH port redirection (the host is headless). Not sure if that matters. diff --git a/results/classifier/accel-gemma3:12b/vmm/812 b/results/classifier/accel-gemma3:12b/vmm/812 new file mode 100644 index 000000000..754dd1b9f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/812 @@ -0,0 +1,125 @@ + +Multicast packets (mDNS) are not sent out of VM +Description of problem: +The app is sending multicast packets (mDNS), but they are not sent out of VM. +Here is the configuration of the network: `-netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::50051-:50051,hostfwd=tcp::50050-:50050` +Steps to reproduce: +1. Install arduino-cli from https://github.com/arduino/arduino-cli/releases (eg. 0.20.2) +2. `arduino-cli config init` +3. `vi ~/.arduino15/arduino-cli.yaml` +4. edit it to have it as follows: +``` +board_manager: + additional_urls: ["http://arduino.esp8266.com/stable/package_esp8266com_index.json"] +daemon: + port: "50051" +directories: + data: /root/app/data + downloads: /root/app/downloads + user: /root/app/user +library: + enable_unsafe_install: false +logging: + file: "" + format: text + level: info +metrics: + addr: :9090 + enabled: false +output: + no_color: false +sketch: + always_export_binaries: false +updater: + enable_notification: true +``` + +5. `arduino-cli core update-index` +6. `arduino-cli core install esp8266:esp8266` +7. `arduino-cli board list -v` + +This will give an output similar to: +``` +INFO[0000] Using config file: /root/.arduino15/arduino-cli.yaml +INFO[0000] arduino-cli.x86_64 version git-snapshot +INFO[0000] Checking if CLI is Bundled into the IDE +INFO[0000] Adding libraries dir dir=/root/app/user/libraries location=user +INFO[0000] Checking signature index=/root/app/data/package_index.json signatureFile=/root/app/data/package_index.json.sig = +INFO[0000] Checking signature error="opening signature file: open /root/app/data/package_esp8266com_index.json.sig: no such file or d= +INFO[0000] Loading hardware from: /root/app/data/packages +INFO[0000] Loading package builtin from: /root/app/data/packages/builtin +INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/builtin/tools +INFO[0000] Loading tools from dir: /root/app/data/packages/builtin/tools +INFO[0000] Loaded tool tool="builtin:ctags@5.8-arduino11" +INFO[0000] Loaded tool tool="builtin:mdns-discovery@1.0.2" +INFO[0000] Loaded tool tool="builtin:serial-discovery@1.3.1" +INFO[0000] Loaded tool tool="builtin:serial-monitor@0.9.1" +INFO[0000] Loading package esp8266 from: /root/app/data/packages/esp8266/hardware +INFO[0000] Checking signature error="opening signature file: open /root/app/data/packages/esp8266/hardware/esp8266/3.0.2/installed.js= +INFO[0000] Adding monitor tool protocol=serial tool="builtin:serial-monitor" +INFO[0000] Loaded platform platform="esp8266:esp8266@3.0.2" +INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/esp8266/tools +INFO[0000] Loading tools from dir: /root/app/data/packages/esp8266/tools +INFO[0000] Loaded tool tool="esp8266:mklittlefs@3.0.4-gcc10.3-1757bed" +INFO[0000] Loaded tool tool="esp8266:mkspiffs@3.0.4-gcc10.3-1757bed" +INFO[0000] Loaded tool tool="esp8266:python3@3.7.2-post1" +INFO[0000] Loaded tool tool="esp8266:xtensa-lx106-elf-gcc@3.0.4-gcc10.3-1757bed" +INFO[0000] Adding libraries dir dir=/root/app/data/packages/esp8266/hardware/esp8266/3.0.2/libraries location=platform +INFO[0007] Executing `arduino-cli board list` +INFO[0007] starting discovery builtin:serial-discovery process +INFO[0007] started discovery builtin:serial-discovery process +INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:serial-discovery +INFO[0007] starting discovery builtin:mdns-discovery process +INFO[0007] started discovery builtin:mdns-discovery process +INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:mdns-discovery +INFO[0007] from discovery builtin:serial-discovery received message type: hello, message: OK, protocol version: 1 +INFO[0007] from discovery builtin:mdns-discovery received message type: hello, message: OK, protocol version: 1 +INFO[0007] sending command START to discovery builtin:serial-discovery +INFO[0007] sending command START to discovery builtin:mdns-discovery +INFO[0007] from discovery builtin:mdns-discovery received message type: start, message: OK +INFO[0007] from discovery builtin:serial-discovery received message type: start, message: OK +INFO[0008] sending command LIST to discovery builtin:serial-discovery +INFO[0008] sending command LIST to discovery builtin:mdns-discovery +INFO[0008] from discovery builtin:mdns-discovery received message type: list +INFO[0008] from discovery builtin:serial-discovery received message type: list, ports: [/dev/ttyS0] +INFO[0008] sending command STOP to discovery builtin:serial-discovery +INFO[0008] sending command STOP to discovery builtin:mdns-discovery +INFO[0008] from discovery builtin:mdns-discovery received message type: stop, message: OK +INFO[0008] from discovery builtin:serial-discovery received message type: stop, message: OK +Port Protocol Type Board Name FQBN Core +/dev/ttyS0 serial Unknown +``` + +Note `builtin:mdns-discovery` discovery started. It is expected to send the packets as follows (the screenshot from the host with Wireshark): + + + +The screenshot is taken if running the same app (but for macOS) from the host and **i can't see the packets sent if executed from the QEMU guest os**. +I believe i either configured it the wrong way (`-netdev user,id=net0,...`) or it's a QEMU bug. +Additional information: +I've tested on macOS host with qemu 6.0.0 and on Linux (Android) host with qemu 6.1.0 and both were not working. + +the network interface seems to be configured for multicasting: +``` +# ifconfig +eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:57 + inet addr:10.0.2.15 Bcast:0.0.0.0 Mask:255.255.255.0 + inet6 addr: fec0::5054:ff:fe12:3457/64 Scope:Site + inet6 addr: fe80::5054:ff:fe12:3457/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:91955 errors:0 dropped:0 overruns:0 frame:0 + TX packets:25203 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:119904373 (114.3 MiB) TX bytes:1868274 (1.7 MiB) + +lo Link encap:Local Loopback + inet addr:127.0.0.1 Mask:255.0.0.0 + inet6 addr: ::1/128 Scope:Host + UP LOOPBACK RUNNING MTU:65536 Metric:1 + RX packets:0 errors:0 dropped:0 overruns:0 frame:0 + TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) +``` + +It might be easier to skip using arduino-cli and just use any mdns discovery app. diff --git a/results/classifier/accel-gemma3:12b/vmm/813 b/results/classifier/accel-gemma3:12b/vmm/813 new file mode 100644 index 000000000..cdab1e194 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/813 @@ -0,0 +1,16 @@ + +On windows, preallocation=full qcow2 not creatable, qcow2 not resizable +Description of problem: +Not possible to create a fixed-virtual-disk qcow as one may do on linux. +One sometimes may want to create a fixed size qcow2, as can be done with the fixed variants of VHDX, VMDK, VDI, + +The advantage of a fixed virtual-disk format, such as fixed-VHDX, fixed-VMDK, fixed-VDI is that it keeps the disk-meta-data as a header bundled along with that is essentially a raw image, allowing for seamless tooling and management of virtual-disks + +Workaround use a raw file as diskimage. (see workaround given below) + +To be very general, the implementation of this may need to factor in what underlying operations (fallocate, fallocate_punchhole, truncate, sparse) are supported by what filesystems (NTFS, ExFAT, ext4), choice of filesystem-driver (sometimes the driver may not have yet implemented an underlying operation), and operating systems (Linux/Win), and possible workarounds to achieve the same effect in the absence of underlying-operation. +Steps to reproduce: +1. open command shell +2. run the qemu-img command. In my case, qcow2 file is attempted to be created on a drive with ExFAT filesystem. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/814 b/results/classifier/accel-gemma3:12b/vmm/814 new file mode 100644 index 000000000..063b70638 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/814 @@ -0,0 +1,38 @@ + +On Windows, qcow2 is corrupted on expansion +Description of problem: +On Windows, the qcow2 loses blocks on account of which the filesystem withing is corrupted as data is copied to it, just the same way as in #727 VHDX is corrupted on expansion on both Linux/Windows. + +After filing a bug for WNBD https://github.com/cloudbase/wnbd/issues/63 , I was suggested to try raw and qcow2. In the process I found that qcow2 is also affected. But it is also true that the kernel-5.15.4 ... 5.15.13 series have also been buggy https://bugzilla.kernel.org/show_bug.cgi?id=215460 . +On Linux, qcow2 never showed any signs of corruption. +On Windows, however, qcow2 does corrupt. + +It is possible that, as Linux is so much more efficient at files and disk-IO, the kernel-block-code, qemu-block-code and qemu-qcow2-code do not hit the bug, and so the corruption does not show up as easily in Linux. Windows, being a little slower at this, might be causing the bug to show up in this qcow2 test. Possibly, the issue more likely to show up on slower machines. I am using an 2013-era intel-4rth gen i7-4700mq Haswell machine. + +It is possible that, the resolution for this issue and that for #727 could be the same or very closely related. The bug may not be in qcow2.c or vhdx.c but maybe in the qemu/block subsystem. If the data-block that arrives from the VM-interface/nbd-interface which has to be written to file, but never gets to the virtual-disk code, not allocated and written to, then the data-block is lost. +Steps to reproduce: +1. Prepare virtual-disk1 as empty qcow2. In my-setup, the qcow2 file resides on an 150 GiB ExFAT partition on 512 GiB SSD. I use ExFAT as the ExFAT-filesystem does not have a concept of sparse files, eliminating that factor from troubleshooting. + ```qemu-img.exe create -f qcow2 H:\gkpics01.qcow2 99723771904``` +2. Prepare virtual-disk2 VHDX with synthetic generated data (sgdata). Scriptlets to recreate sgdata are described in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 . In my-setup, the vhdx file resides on an 1 TiB NTFS partition on a 2 TiB HDD. +3. Start qemu with arguments as given above. +4. Inside VM, boot and bringup livecd desktop, close the installer and open a terminal +5. Use gdisk to put an ext4 partition on /dev/sda +6. Put ext4 partition on sda1 ```mkfs.ext4 -L fs_gkpics01 /dev/sda1``` +7. Create mount directories ```mkdir /mnt/a /mnt/b``` +8. Mount the empty partition from virtual-disk-1 ```mount -t ext4 /dev/sda1 /mnt/a``` +9. Mount the sgdata partition from virtual-disk-2 ```mount.ntfs-3g /dev/sdb2 /mnt/b``` or ```mount -t ntfs3 /dev/sdb2 /mnt/b``` +10. Keep a terminal tab open with ```dmesg -w``` running +11. Rsync sgdata ```( sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date )``` +12. Check sha256sum ```( sdate=`date` ; cd /mnt/a/photos001 ; shas256sum -c ./find.CHECKSUM --quiet ; echo $sdate ; date )``` + corruption will show even without needing to unmount-remount or reboot-remount. + +- About 1.4 GiB free-space left on the ext4 partition. +- Compared to #727, The number of files corrupted are less ``` sha256sum: WARNING: 31 computed checksums did not match ``` +- After, VM guest OS warm reboot, a recheck of the sha256sum shows the same 31 files as corrupted +- After, qemu poweroff, restart qemu, VM guest OS cold boot, a recheck of the sha256sum shows the same 31 files as corrupted +- df shows: sda1 has 95271336 1k-blocks, of which 88840860 are used, 1544820 available, 99% used. The numbers don't add up. Either file-blocks are lost in lost-clusters or the ext4-filesystem has a large journal or the file-system-metadata is too large, or the ext4-filesystem has large cluster-size which results in inefficient space usage. +- An ```unmount /dev/sda1 ; fsck -y /dev/sda1 ; mount -t ext4 /dev/sda1 /mnt/a``` did not find any lost clusters. + +The reason I don't think this is a kernel bug, is because the raw-file as virtual-disk-1 doesn't show this issue. Also, it happens regardless of whether sgdata is on ntfs-3g or ntfs3-paragon. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/814222 b/results/classifier/accel-gemma3:12b/vmm/814222 new file mode 100644 index 000000000..1a749de0a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/814222 @@ -0,0 +1,127 @@ + +kvm cannot use vhd files over 127GB + +The primary use case for using vhds with KVM is to perform a conversion to a raw image file so that one could move from Hyper-V to Linux-KVM. See more on this http://blog.allanglesit.com/2011/03/linux-kvm-migrating-hyper-v-vhd-images-to-kvm/ + +# kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img + +The above works great if you have VHDs smaller than 127GB, however if it is larger, then no error is generated during the conversion process, but it appears to just process up to that 127GB barrier and no more. Also of note. VHDs can also be run directly using KVM if they are smaller than 127GB. VHDs can be read and function well using virtualbox as well as hyper-v, so I suspect the problem lies not with the VHD format (since that has a 2TB limitation). But instead with how qemu-kvm is interpreting them. + +BORING VERSION INFO: +# cat /etc/issue +Ubuntu 11.04 \n \l +# uname -rmiv +2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 +# apt-cache policy kvm +kvm: + Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 + Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 + Version table: + *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0 + 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages + 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0 + 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages +# apt-cache policy libvirt-bin +libvirt-bin: + Installed: 0.8.8-1ubuntu6.2 + Candidate: 0.8.8-1ubuntu6.2 + Version table: + *** 0.8.8-1ubuntu6.2 0 + 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages + 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages + 100 /var/lib/dpkg/status + 0.8.8-1ubuntu6 0 + 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages + +qemu-img version 0.14.0 + +# vboxmanage -v +4.0.12r72916 + + +REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with < 1GB of free space) + +## WINDOWS MACHINE ## + +Use Computer Management > Disk Management +-Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively. +-Do not initialize or format. + +These files will need to be transferred to an Ubuntu KVM machine (pscp is what I used but usb would work as well). + +## UBUNTU KVM MACHINE ## + +# ls *.vhd +120g-dyn.vhd 140g-dyn.vhd +# kvm-img info 120g-dyn.vhd +image: 120g-dyn.vhd +file format: vpc +virtual size: 120G (128847052800 bytes) +disk size: 244K +# kvm-img info 140g-dyn.vhd +image: 140g-dyn.vhd +file format: vpc +virtual size: 127G (136899993600 bytes) +disk size: 284K +# kvm-img info 120g-dyn.vhd | grep "virtual size" +virtual size: 120G (128847052800 bytes) +# kvm-img info 140g-dyn.vhd | grep "virtual size" +virtual size: 127G (136899993600 bytes) + +Regardless of how big the second vhd is I always get a virtual size of 127G + +Now if we use virtualbox to view the vhds we see markedly different results. + +# VBoxManage showhdinfo 120g-dyn.vhd +UUID: e63681e0-ff12-4114-85de-7d13562b36db +Accessible: yes +Logical size: 122880 MBytes +Current size on disk: 0 MBytes +Type: normal (base) +Storage format: VHD +Format variant: dynamic default +Location: /root/120g-dyn.vhd +# VBoxManage showhdinfo 140g-dyn.vhd +UUID: 94531905-46b4-469f-bb44-7a7d388fb38f +Accessible: yes +Logical size: 143360 MBytes +Current size on disk: 0 MBytes +Type: normal (base) +Storage format: VHD +Format variant: dynamic default +Location: /root/140g-dyn.vhd + +# kvm-img convert -f vpc -O raw 120g-dyn.vhd 120g-dyn.img +# +# kvm-img convert -f vpc -O raw 140g-dyn.vhd 140g-dyn.img +# + +# kvm-img info 120g-dyn.img +image: 120g-dyn.img +file format: raw +virtual size: 120G (128847052800 bytes) +disk size: 0 +# kvm-img info 120g-dyn.img | grep "virtual size" +virtual size: 120G (128847052800 bytes) +# kvm-img info 140g-dyn.img +image: 140g-dyn.img +file format: raw +virtual size: 127G (136899993600 bytes) +disk size: 0 +# kvm-img info 140g-dyn.img | grep "virtual size" +virtual size: 127G (136899993600 bytes) + +Notice after the conversion the raw image will the taken on the partial geometry of the vhd, thus rendering that image invalid. + +vboxmanage has a clonehd option which allows you to successfully convert vhd to a raw image, which kvm then sees properly. + +For giggles I also tested with a 140GB fixed VHD (in the same manner as above) and it displayed the virtual size as correct, so a good work around is to convert your VHDs to fixed, then use kvm-img to convert them. + +Keep in mind that these reproduction steps will not have a file systems therefore no valid data, if there were for example NTFS with a text file the problem would still occur but more importantly the guest trying to use it would not be able to open the disk because of it being unable to find the final sector. + +So long story short I think we are dealing with 2 issues here. + +1) kvm not being able to deal with dynamic VHD files larger than 127GB +2) kvm-img not generating an error when it "fails" at converting or displaying information on dynamic VHDs larger than 127GB. The error should be something like "qemu-kvm does not support dynamic VHD files larger that 127GB..." \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/815 b/results/classifier/accel-gemma3:12b/vmm/815 new file mode 100644 index 000000000..cef8f4bb6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/815 @@ -0,0 +1,2 @@ + +Using spdk Vhost to accelerate QEMU, which QEMU version is the most appropriate？ diff --git a/results/classifier/accel-gemma3:12b/vmm/824074 b/results/classifier/accel-gemma3:12b/vmm/824074 new file mode 100644 index 000000000..4e1de2704 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/824074 @@ -0,0 +1,6 @@ + +Provide runtime option to expose the supported list of keymaps for vnc + +As discussed in the ganeti group[1], I'm opening this bug to request that qemu provides a runtime command or switch to list the supported keymaps for vnc. + + [1] - http://groups.google.com/group/ganeti/browse_thread/thread/dd524f5311d8d79e \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/829455 b/results/classifier/accel-gemma3:12b/vmm/829455 new file mode 100644 index 000000000..6fd58126d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/829455 @@ -0,0 +1,17 @@ + +user mode network stack - hostfwd not working with restrict=y + +I find that explicit hostfwd commands do not seem to work with restrict=yes option, even if the docs clearly state that hostfwd should override restrict setting. + +I am using this config: + +-net user,name=test,net=192.168.100.0/24,host=192.168.100.44,restrict=y,hostfwd=tcp:127.0.0.1:3389-192.168.100.1:3389 + +(my guest has static IP address configured as 192.168.100.1/24) + +and I cannot log into my guest via rdp. the client hanging indefinitely. +by just changing to "restrict=no" I can log in. + +maybe I am doing something wrong, but I cannot figure out what. + +running QEMU emulator version 0.14.0 (qemu-kvm-0.14.0) \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/832 b/results/classifier/accel-gemma3:12b/vmm/832 new file mode 100644 index 000000000..2410f53d7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/832 @@ -0,0 +1,14 @@ + +error "# mkdir('/..../qtest-9p-local-M33XsI') failed: File exists" on every run of 'qos-test' +Description of problem: +``` +$ ./build//tests/qtest/qos-test -h +# mkdir('/home/berrange/src/virt/qemu/qtest-9p-local-qThj5y') failed: File exists +Usage: + ./build//tests/qtest/qos-test [OPTION...] +...snip... +``` + +Notice the error message from 'mkdir()' whic appears every time you run this program. +Steps to reproduce: +1. Run qos-test diff --git a/results/classifier/accel-gemma3:12b/vmm/840 b/results/classifier/accel-gemma3:12b/vmm/840 new file mode 100644 index 000000000..fe22d57ec --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/840 @@ -0,0 +1,11 @@ + +When O2 level is enabled raspi3b board crash randomly when creating abuffer of a differnt size +Description of problem: +Sometimes when running the code creating a framebuffer different from the default size ej:1024x768 qemu hangs and crash with a SIGV, making a weird screen that's painted with the original size and the background of the current window merged onto a large window. This happens when you resize a window without updating it's contents, so qemu is crashing before the first frame after reising the window. +Steps to reproduce: +1. Create a producedure similar to the one descrived below +2. Run qemu with O2 enabled(debuggind disabled) +3. You may need to run it multiple times to see the bug(like two or three times) +Additional information: +Here is the example procedure implemented on rust, the mailbox interface is test and it's sure that the procedure it's well implemented: +[code.rs](/uploads/a28fe33a856fb843d80ffeb078bc6729/code.rs) diff --git a/results/classifier/accel-gemma3:12b/vmm/845 b/results/classifier/accel-gemma3:12b/vmm/845 new file mode 100644 index 000000000..a4df35c49 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/845 @@ -0,0 +1,60 @@ + +Heap-use-after-free in remote_object_finalize +Description of problem: +While I was working with `QIOChannel` in my downstream QEMU fork, I looked at `hw/remote/remote-obj.c` as a usage example. + +I did the same thing to `remote_object_finalize` function in order to free the QIOChannel when the connection closed: + +```c + if (o->ioc) { + qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL); + qio_channel_close(o->ioc, NULL); + } + + object_unref(OBJECT(o->ioc)); +``` + +After the connection is closed for a while, my program SIGSEGV: + +``` +Thread 2 Crashed: +0 qemu-system-aarch64 0x000000010164513c qemu_coroutine_get_aio_context + 12 (qemu-coroutine.c:203) +1 qemu-system-aarch64 0x000000010145ad82 qio_channel_restart_read + 50 +2 qemu-system-aarch64 0x0000000101614c8a aio_dispatch_handler + 378 (aio-posix.c:332) +3 qemu-system-aarch64 0x0000000101613fad aio_dispatch_handlers + 125 (aio-posix.c:372) +4 qemu-system-aarch64 0x0000000101613ef3 aio_dispatch + 51 (aio-posix.c:383) +5 qemu-system-aarch64 0x0000000101631e18 aio_ctx_dispatch + 104 (async.c:307) +6 libglib-2.0.0.dylib 0x000000010284b90c g_main_context_dispatch + 364 +7 qemu-system-aarch64 0x0000000101644728 glib_pollfds_poll + 88 (main-loop.c:233) +8 qemu-system-aarch64 0x0000000101644170 os_host_main_loop_wait + 128 (main-loop.c:256) +9 qemu-system-aarch64 0x000000010164403c main_loop_wait + 188 (main-loop.c:530) +10 qemu-system-aarch64 0x00000001012f3014 qemu_main_loop + 36 (runstate.c:721) +11 qemu-system-aarch64 0x0000000100c25e38 qemu_main + 40 (main.c:51) +12 qemu-system-aarch64 0x0000000100c7b1f4 call_qemu_main + 52 (cocoa.m:1746) +13 qemu-system-aarch64 0x000000010161a459 qemu_thread_start + 185 (qemu-thread-posix.c:521) +14 libsystem_pthread.dylib 0x00007fff6a6e2109 _pthread_start + 148 +15 libsystem_pthread.dylib 0x00007fff6a6ddb8b thread_start + 15 +``` + +So apparently, there is a dangling pointer of the QIOChannel in AIOContext. + +And indeed, that caused by the fact that when the fd read/write is blocked, it sets the fd handlers to the AIO context before yielding the coroutine (https://gitlab.com/qemu-project/qemu/-/blob/master/io/channel.c#L544). + +So after the fd is closed, the AIO still dispatches the fd readable event when the main loop dispatches again, using the dangling QIOChannel pointer (When the fd is reused I think). + +I suggest adding a `qio_channel_detach_aio_context()` call before the channel is shutdown in `remote-obj.c`, or before the fd is closed in `qio_channel_close()` in `io/channel.c` + +```c + + if (o->ioc) { + qio_channel_detach_aio_context(o->ioc); + qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL); + qio_channel_close(o->ioc, NULL); + } + + object_unref(OBJECT(o->ioc)); +``` + +This bug might have slipped through the cracks because `mpqemu_remote_msg_loop_co` issues a shutdown request immediately after an I/O error occured on the QIOChannel. +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/849 b/results/classifier/accel-gemma3:12b/vmm/849 new file mode 100644 index 000000000..6b698990d --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/849 @@ -0,0 +1,23 @@ + +High mouse polling rate stutters some applications +Description of problem: +There are couple of instances where moving the mouse would slow down some applications, especially for games + +https://www.reddit.com/r/VFIO/comments/ect3sd/having_an_issue_with_my_vm_where_games_stutter/ + +https://www.reddit.com/r/VFIO/comments/n9hwtg/game_fps_drop_on_mouse_input/ + +https://www.reddit.com/r/VFIO/comments/ln1uwb/evdev_mouse_passthrough_with_1000hz_mouse_causes/ + +https://www.reddit.com/r/VFIO/comments/se92rq/looking_for_advice_on_poor_gpu_passthrough/ + +I myself included, is impacted by this mysterious issue, I'm not pretty sure whether this is related to VFIO or QEMU or both, but I'm definitely sure this is a kind of regression in between since I had no such issue before. +Steps to reproduce: +1. Do a GPU passthrough +2. Get a mouse capable of outputting high polling rate like 1000Hz, usually they are categorized as gaming mouses +3. Start any 3D applications, including stuff like Unreal Engine 4 Editor or any games +4. See mysterious stuttering +Additional information: +I'm using an AMD Ryzen 7 3700X CPU as the host, but I have made scripts that pins CPU to the VM to get better performance speculatively by putting the threads on the same CCX to minimize memory latency as much as possible. This alleviated some terrible lag, but not by much. (like 11 FPS to 20 FPS if you move your mouse which is still crappy compared to 90+ FPS when static) + +I suspect there is something wrong with the USB subsystem. diff --git a/results/classifier/accel-gemma3:12b/vmm/858 b/results/classifier/accel-gemma3:12b/vmm/858 new file mode 100644 index 000000000..5c6db65ed --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/858 @@ -0,0 +1,12 @@ + +qemu-system-x86_64: WHPX: Unexpected VP exit code 4 +Description of problem: +Qemu closes and prints following message: + +WHPX: setting APIC emulation mode in the hypervisor +Windows Hypervisor Platform accelerator is operational +whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005) +qemu-system-x86_64: WHPX: Unexpected VP exit code 4 +Steps to reproduce: +1. build OVMF firmware from edk2 +2. run cmd : qemu-system-x86_64 -accel whpx --bios D:\Projects\FW\uefi\edk2\Build\OvmfX64\DEBUG_VS2019\FV\OVMF.fd diff --git a/results/classifier/accel-gemma3:12b/vmm/864 b/results/classifier/accel-gemma3:12b/vmm/864 new file mode 100644 index 000000000..ca986b2a6 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/864 @@ -0,0 +1,16 @@ + +HVF virtual counter diverges from CLOCK_VIRTUAL when the host sleeps +Description of problem: +HVF's virtual counter diverges from `CLOCK_VIRTUAL` when the host sleeps and causes the inconsistency between Linux's system counter and everything else. + +HVF's virtual counter apparently relies on something similar to `mach_absolute_time`, which stops when the host sleeps and resumes after it wakes up. However, `CLOCK_VIRTUAL` is implemented with `mach_continuous_time`, which continues even while the host sleeps. Linux uses the virtual counter as the source of the system counter and sees inconsistencies between the system counter and the other devices. +Steps to reproduce: +1. Launch Fedora. +2. Compare the time shown at the top of the guest display and one at the top of the host display. The difference should be less than 2 minutes. +3. Let the host sleep for 3 minutes. +4. Compare the times again. The difference is now greater than 2 minutes. +Additional information: +Here are solutions I've came up with so far. There are trade-offs but any of them should be better than the current situation. I'm happy to implement one if the maintainers have decided which one is the best or figure out a superior alternative. +- Implement `cpus_get_virtual_clock` of `AccelOpsClass` with `mach_absolute_time`. It would make HVF inconsistent with the other accelerators. Linux also expects the virtual clock is "continuous" and it leaves the divergence from the real time. +- Request XNU `HOST_NOTIFY_CALENDAR_CHANGE` to update the virtual clock with the continuous time. The interface is undocumented. +- Use `IORegisterForSystemPower` to update the virtual clock with the continuous time. It is undocumented that the interface handles every cases where `mach_absolute_time` and `mach_continuous_time`, but it actually does if I read XNU's source code correctly. diff --git a/results/classifier/accel-gemma3:12b/vmm/864490 b/results/classifier/accel-gemma3:12b/vmm/864490 new file mode 100644 index 000000000..fb497cda4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/864490 @@ -0,0 +1,11 @@ + +Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core + +This issue has been giving headache to us since a long time. +Difficult to reproduce as it happens randomly. +We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests in either XEN 3.3 or Proxmox environments. +When only one CPU core is assigned to the guest, everything is fine. If 2 or more cores are assigned, the guest stops responding after several hours - and in the host machine one of the cores is using 100%. The only thing that helps is resetting the guest. + +I am ready to provide logs/crashdumps if needed, because we want to help resolve this issue. I saw some posts on the web of people having the same problems - for some of the workaround was to fix some BIOS settings, but we did not have success with those (e.g. disabling C1E Support and Intel C-State ) + +Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/865 b/results/classifier/accel-gemma3:12b/vmm/865 new file mode 100644 index 000000000..a6793e3ae --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/865 @@ -0,0 +1,46 @@ + +virtio-vga gtk,gl=on Black Screen or GLXGears picture +Description of problem: +Blank screen for tab with name `virtio-vga` on GTK interface, however, if I run `glxgears` before running the machine, I see the following image: + + +Steps to reproduce: +1.Run the invocation command provided above + +# +Additional information: +The host when the problem is occurring is a Dell Precision 5110 laptop that have Hybrid Graphics. I am running X11 with nvidia as the main driver, I am not using nouveau, I am using the nvidia drivers installed by the debian package, here the corresponding information for the nvida card: + +``` +nvidia-smi +``` +``` +Thu Feb 10 23:32:21 2022 ++-----------------------------------------------------------------------------+ +| NVIDIA-SMI 460.91.03 Driver Version: 460.91.03 CUDA Version: 11.2 | +|-------------------------------+----------------------+----------------------+ +| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | +| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | +| | | MIG M. | +|===============================+======================+======================| +| 0 Quadro M1000M On | 00000000:01:00.0 Off | N/A | +| N/A 44C P8 N/A / N/A | 846MiB / 2004MiB | 6% Default | +| | | N/A | ++-------------------------------+----------------------+----------------------+ + ++-----------------------------------------------------------------------------+ +| Processes: | +| GPU GI CI PID Type Process name GPU Memory | +| ID ID Usage | +|=============================================================================| +| 0 N/A N/A 6926 G /usr/lib/xorg/Xorg 528MiB | +| 0 N/A N/A 7223 G ...b/firefox-esr/firefox-esr 238MiB | +| 0 N/A N/A 7363 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 276992 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 282023 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 282630 G ...b/firefox-esr/firefox-esr 0MiB | +| 0 N/A N/A 322305 G qemu-system-x86_64 70MiB | ++-----------------------------------------------------------------------------+ +``` + +## diff --git a/results/classifier/accel-gemma3:12b/vmm/873460 b/results/classifier/accel-gemma3:12b/vmm/873460 new file mode 100644 index 000000000..170e9b2c4 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/873460 @@ -0,0 +1,9 @@ + +Likewise no sound + +Hi, +using fresh Ubuntu 11.10 with Likewise 6 in a MS Domain. +Domain users log with no sound. +Local users are OK. + +Thx \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/88 b/results/classifier/accel-gemma3:12b/vmm/88 new file mode 100644 index 000000000..8556c7bbe --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/88 @@ -0,0 +1,2 @@ + +VNC server does not work with Mac Screen Sharing diff --git a/results/classifier/accel-gemma3:12b/vmm/881 b/results/classifier/accel-gemma3:12b/vmm/881 new file mode 100644 index 000000000..5ee00adbd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/881 @@ -0,0 +1,21 @@ + +qemu-ga fs-freeze causes VM to +Description of problem: +I have fresh install of Debian 11 and installed MariaDB 10.7 from MariaDB's Repo. Guest is fully up to date. +When Proxmox goes to do a backup it will call fs-freeze to the VM via the agent which then causes the backup process to hang and the VM will lockup or causes kernel message such as `**task qemu-ga:370 blocked for more than 120 seconds**`. The VM from what I can tell no longer is able to write to disk, and the only fix is to force reset the VM. + +The issue doesn't happen when the VM has first started or the agent has been restart from what I can tell, but if you leave it and wait for the nightly backup to run of the VM, it will then cause this issue to happen. + +There are other reports of this happening on the [proxmox forums](https://forum.proxmox.com/threads/snapshot-backup-not-working-guest-agent-fs-freeze-gets-timeout.99887/) More details on this topic. Other reports with the issue with MariaDB 10.6. + +My other Debian 11 VMs which were also setup recently, do not experience this problem, only difference is this VM is running the MariaDB. I have Gitlab, Docker, Mailcow, PowerDNS, OPNsense (each of these separate VM) in the other VMs and they do not experience this issue. All these VMs are running Debian 11. + +Agent Info +``` +qemu-guest-agent/stable,stable-security,now 1:5.2+dfsg-11+deb11u1 amd64 +``` +Steps to reproduce: +1. Install Proxmox (although I would assume any QEMU 6.1.1) +2. Create a Debian 11 guest with MariaDB 10.7 from MariaDB repo +3. Wait good few hours +4. Issue a backup or fs-freeze diff --git a/results/classifier/accel-gemma3:12b/vmm/883 b/results/classifier/accel-gemma3:12b/vmm/883 new file mode 100644 index 000000000..a4298fc46 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/883 @@ -0,0 +1,28 @@ + +DRBG: could not allocate CTR cipher TFM handle: ctr(aes) +Description of problem: + +Steps to reproduce: +1. Install Debian in Qemu using the command: +``` +REM example to create disk +REM qemu-img create -f qcow2 debian-qcow2.img 32G + +qemu-system-x86_64.exe -hda debian-qcow2.img -cdrom debian-11.2.0-amd64-netinst.iso -boot d -m 8G -accel hax +``` + +2. Fight with installer and partitions to finally get this: + + +3. System boots and shows a bunch of FAILED messages with crypto error: + + + + +I am new at using Qemu so may need pointers to provide more information. + +The system seems to be working to some degree. + +Color me impressed!!! +Additional information: +Related: #880 diff --git a/results/classifier/accel-gemma3:12b/vmm/886147 b/results/classifier/accel-gemma3:12b/vmm/886147 new file mode 100644 index 000000000..74830aa10 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/886147 @@ -0,0 +1,12 @@ + +Cannot make program Icon on my desktop with rightmouse key + +Howdy Xubuntu users + +How can I make a "starter program Icon on my desktop" with the mouse command right key. + +I do not seen the commands when I hit the right key of my mouse. + +Hope to see some info in my pigeon-hole. + +Spidey-Westland \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/887 b/results/classifier/accel-gemma3:12b/vmm/887 new file mode 100644 index 000000000..fad729d74 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/887 @@ -0,0 +1,2 @@ + +OSX Sorbet Leopard 10.5.9 on QEMU ? diff --git a/results/classifier/accel-gemma3:12b/vmm/894037 b/results/classifier/accel-gemma3:12b/vmm/894037 new file mode 100644 index 000000000..a94d06bcd --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/894037 @@ -0,0 +1,16 @@ + +With VNC, "-usbdevice tablet" no longer makes mouse pointers line up + +I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. + +Here's how I'm booting WinXP: + +qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & + +The Windows install hasn't changed, only qemu. + +I'm running this version of QEMU: + +QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard + +I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/895 b/results/classifier/accel-gemma3:12b/vmm/895 new file mode 100644 index 000000000..2d66bbda7 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/895 @@ -0,0 +1,39 @@ + +can't find table device while call qemu_input_is_absolute function +Description of problem: +vnc service can‘t run with mouse absolute mode +Steps to reproduce: +1.create a virtual machine with vnc service via virt-manager. + +2.delete mouse and table device if exists. + +3.add table devices first,next add mouse device. + +4.gdb attach corresponding qemu thread, run command +print "%d",qemu_input_is_absolute() +display function return false ,so I can't use mouse with absolute mode. +Additional information: +code in qemu_input_is_absolute() is +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_REL | INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +qemu_input_find_handler function find a handler INPUT_EVENT_MASK_REL or INPUT_EVENT_MASK_ABS,but just compare with INPUT_EVENT_MASK_ABS, +I think it should be +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +thanks for your help. diff --git a/results/classifier/accel-gemma3:12b/vmm/899140 b/results/classifier/accel-gemma3:12b/vmm/899140 new file mode 100644 index 000000000..685a5f4bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/899140 @@ -0,0 +1,25 @@ + +Problem with Linux Kernel Traffic Control + +Hi, + +The two last main versions of QEMU (0.15 and 1.0) have an important problem when running on a Linux distribution which running itself a Traffic Control (TC) instance. +Indeed, when TC is configured with a Token Bucket Filter (TBF) with a particular rate, the effective rate is very slower than the desired one. + +For instance, lets consider the following configuration : + +# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms + +The effective rate will be about 100kbit/s ! (verified with iperf) +I've encountered this problem on versions 0.15 and 1.0 but not with the 0.14... +In the 0.14, we have a rate of 19.2 mbit/s which is quiet normal. + +I've done the experimentation on several hosts : + +- Debian 32bit core i7, 4GB RAM +- Debian 64bit core i7, 8GB RAM +- 3 different high performance servers : Ubuntu 64 bits, 48 AMD Opteron, 128GB of RAM + +The problem is always the same... The problem is also seen with a Class Based Queuing (CBQ) in TC. + +Thanks \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/901 b/results/classifier/accel-gemma3:12b/vmm/901 new file mode 100644 index 000000000..565d7d62b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/901 @@ -0,0 +1,11 @@ + +Bad screen behavior with adaptive sync +Description of problem: +KDE Wayland has freesync automatically enabled for full screen applications[[1]](https://wiki.archlinux.org/title/Variable_refresh_rate#Wayland_configuration). When using a VM in full screen mode, the screen starts having a strange behavior, like "blinking". I've tried windows 10, Linux Mint, MX Linux and Ubuntu 21.10. +The problem disappears if using Xorg or disabling freesync trough KDE settings. +Steps to reproduce: +1. On KDE Wayland, check if freesync is activated in settings> screen> adaptive synchronization +2. Launch any vm in fuul screen mode +3. Observe the screen +Additional information: + diff --git a/results/classifier/accel-gemma3:12b/vmm/902720 b/results/classifier/accel-gemma3:12b/vmm/902720 new file mode 100644 index 000000000..49ea6b347 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/902720 @@ -0,0 +1,17 @@ + +TIME_MAX not set correctly for OpenBSD in qemu-common.h + +Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code. +OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit). + + CC i386-softmmu/monitor.o +/buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password': +/buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion + +qemu-common.h has... + +#ifndef TIME_MAX +#define TIME_MAX LONG_MAX +#endif + +for OpenBSD this should be INT_MAX. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/903365 b/results/classifier/accel-gemma3:12b/vmm/903365 new file mode 100644 index 000000000..444bc8b36 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/903365 @@ -0,0 +1,4 @@ + +[feature request] bind nat (-net user) to other interface (like eth0:2) + +-net user mode is very nice because it does not require any changes in host system. However if host system has muplitple IPs You cant use it, or even switch to another. Qemu should be able to "bind" to eth0:1 eth0:2 so that outgoing traffic uses this interface and thus other IP. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/906221 b/results/classifier/accel-gemma3:12b/vmm/906221 new file mode 100644 index 000000000..94c676a37 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/906221 @@ -0,0 +1,33 @@ + +USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0 + +When connecting a USB DVD/CDROM drive to the linux host, it works fine and I can mount the inserted DVD properly and work with it. After unmounting the DVD and routing the USB drive to the linux guest (same kernel version), both host and guest become unresponsive and on the QEMU console I get the QEMU console flodded with the message: +USBDEVFS_CLEAR_HALT: Connection timed out +again and again, approx. each 10-20 seconds. + +When I unplug the device from the host, the message +USBDEVFS_CLEAR_HALT: No such device +comes up in one block at least 100 times (my scrollback history of the display is limited, so I cannot say how often it actually appreared) + +On the guest side linux, I see the following dmesg after having it routed from the host to the guest: +[ 160.292231] usb 1-2.1: new full speed USB device using uhci_hcd and address 5 +[ 160.475762] usb 1-2.1: configuration #1 chosen from 1 choice +[ 160.478553] scsi3 : SCSI emulation for USB Mass Storage devices +[ 160.479689] usb-storage: device found at 5 +[ 160.480121] usb-storage: waiting for device to settle before scanning +[ 165.494016] scsi 3:0:0:0: CD-ROM slimtype eTDU108 1 SL03 PQ: 0 ANSI: 0 + +then, the guest stalls and on the host side the USBDEVFS_CLEAR_HALT appears until I unplug the hardware from the host - pay also attention on the stalled dmesg timestamp! The "real" timegap between the last line above and the first line below is more than 20 seconds! + +[ 165.645735] usb 1-2.1: USB disconnect, address 5 +[ 165.663770] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda pop-up +[ 165.664416] sr 3:0:0:0: Attached scsi CD-ROM sr0 +[ 165.664623] sr 3:0:0:0: Attached scsi generic sg1 type 5 +[ 165.665565] usb-storage: device scan complete + +The drive used is a self-powered LITEON External Slim DVD-ROM Drive (Model number eTDU108-02 1) +The power is not a problem, because the drive works fine on the host directly. + +Best regards, + +Erik \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/925405 b/results/classifier/accel-gemma3:12b/vmm/925405 new file mode 100644 index 000000000..b438a8999 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/925405 @@ -0,0 +1,19 @@ + +VNC server does not work with Mac Screen Sharing + +When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. + +I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. + +It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. + +Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. + +Background info: + +Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: + +* At a terminal, by typing "open vnc://hostname:tcp_port" +* From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port + +Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/934 b/results/classifier/accel-gemma3:12b/vmm/934 new file mode 100644 index 000000000..92b98d36b --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/934 @@ -0,0 +1,46 @@ + +VM execution fails for tianocore edk2 ovmf uefi based image on windows whpx +Description of problem: +Cannot do a UEFI tianocore boot of image with linux installation. + +I think the BIOS/UEFI/firmware when run inside a virtual-machine should be oblivious to the type of hypervisor, just probe and enable the emulated hardware. Maybe WHPX is not enabling pflash devices properly. + +My goal is to create a 40Gb fedora linux image with a on-image UEFI boot sequence that I can +1. native boot using ventoy (works) +2. boot using kvm/qemu in linux (works) +3. boot using whpx/qemu in windows (no success yet) + +My original sequence of steps to reproduce was. +1. Under Linux, in qemu-vm, create a bootable linux image by installing from the fedora livecd installer +2. Confirm qemu-VM/fedora installation/UEFI boot works fine under Linux/kvm/qemu. One can see tianocore logo booting up. +3. reboot to windows +4. attempt to boot with analogous windows qemu command. confirm boot failure and error message +5. remove ```-accel whpx``` and rerun, confirm boot succeeds with tianocore image, albeit un-accelarated + +It turns out the image creation is not required. + +The below works under linux +``` +XDG_RUNTIME_DIR=/run/user/1000 qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/OVMF_VARS.fd" -drive "index=2,format=raw,file=/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy" -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait +``` +The below does not work under windows +``` +qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" -drive "index=1,if=pflash,format=raw,file=E:/vstorage/OVMF_VARS.fd" -drive "index=2,if=virtio,media=disk,format=raw,file=H:\m01_lnx.raw.img" -drive "index=3,if=virtio,media=disk,format=raw,file=H:\gkpics01.raw.img" -drive "index=4,if=virtio,media=disk,format=vhdx,file=E:\test\sgdata.vhdx" -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15 -device virtio-net,netdev=vmnic1 -qmp "tcp:127.0.0.1:5955,server,nowait" +: +Windows Hypervisor Platform accelerator is operational +qemu-system-x86_64: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64: WHPX: Failed to exec a virtual processor +``` + +The image does boot if one removes the hardware hypervisor argument ```-accel whpx``` +Steps to reproduce: +The full qemu command with disk images is not required. Just the accel whpx and the pflash devices are sufficient. +1. Confirm that the VM does not execute with the command +``` +qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -boot c -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" +``` +2. Confirm that the VM does execute and tianocore logo shoes up when ```-accel whpx ``` is removed. +Additional information: +- In the planned changes of Fedora 37, going forward, fedora installer will no longer support installing fresh to machines with legacy BIOS and will necessarily require UEFI boot. This means that there is urgency in allowing this mode of booting. + - https://fedoraproject.org/wiki/Releases/37/ChangeSet + - https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS diff --git a/results/classifier/accel-gemma3:12b/vmm/951 b/results/classifier/accel-gemma3:12b/vmm/951 new file mode 100644 index 000000000..121a5d7a0 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/951 @@ -0,0 +1,196 @@ + +Build error +Description of problem: +``` +changing dir to build for make ""... +make[1]: Entering directory '/qemu-git/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/1037] Generating ar with a custom command +[2/1037] Generating bepo with a custom command +[3/1037] Generating cz with a custom command +[4/1037] Generating da with a custom command +[5/1037] Generating de with a custom command +[6/1037] Generating de-ch with a custom command +[7/1037] Generating en-gb with a custom command +[8/1037] Generating en-us with a custom command +[9/1037] Generating es with a custom command +[10/1037] Generating et with a custom command +[11/1037] Generating fi with a custom command +[12/1037] Generating fo with a custom command +[13/1037] Generating fr-be with a custom command +[14/1037] Generating fr with a custom command +[15/1037] Generating fr-ca with a custom command +[16/1037] Generating fr-ch with a custom command +[17/1037] Generating hr with a custom command +[18/1037] Generating hu with a custom command +[19/1037] Generating is with a custom command +[20/1037] Generating it with a custom command +[21/1037] Generating ja with a custom command +[22/1037] Generating lt with a custom command +[23/1037] Generating mk with a custom command +[24/1037] Generating lv with a custom command +[25/1037] Generating nl with a custom command +[26/1037] Generating no with a custom command +[27/1037] Generating pt with a custom command +[28/1037] Generating pl with a custom command +[29/1037] Generating ru with a custom command +[30/1037] Generating pt-br with a custom command +[31/1037] Generating th with a custom command +[32/1037] Generating tr with a custom command +[33/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_i64.c.o +[34/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_common.c.o +[35/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_ui32.c.o +[36/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_random.c.o +[37/1037] Generating Test QAPI files with a custom command +[38/1037] Generating QAPI test (include) with a custom command +[39/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_uint128.c.o +[40/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_functions_common.c.o +[41/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_extF80.c.o +[42/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_functionInfos.c.o +[43/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_ui64.c.o +[44/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f16.c.o +[45/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_i32.c.o +[46/1037] Generating edk2-i386-vars.fd with a custom command (wrapped by meson to capture output) +[47/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_uint128_inline.c.o +[48/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_standardFunctionInfos.c.o +[49/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_fail.c.o +[50/1037] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[51/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f32.c.o +[52/1034] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_s_eq128.c.o +[53/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_writeTestsTotal.c.o +[54/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f64.c.o +[55/1034] Generating edk2-x86_64-code.fd with a custom command (wrapped by meson to capture output) +[56/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f128.c.o +[57/1034] Generating edk2-x86_64-secure-code.fd with a custom command (wrapped by meson to capture output) +[58/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-iova-tree.c.o +[59/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-shadow-virtqueue.c.o +[60/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o +FAILED: libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o +cc -m64 -mcx16 -Ilibqemu-x86_64-softmmu.fa.p -I. -I.. -Itarget/i386 -I../target/i386 -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /qemu-git/qemu/linux-headers -isystem linux-headers -iquote . -iquote /qemu-git/qemu -iquote /qemu-git/qemu/include -iquote /qemu-git/qemu/disas/libvixl -iquote /qemu-git/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="x86_64-softmmu-config-target.h"' '-DCONFIG_DEVICES="x86_64-softmmu-config-devices.h"' -MD -MQ libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -MF libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o.d -o libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -c ../hw/vfio/pci-quirks.c +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_gtt_max’: +../hw/vfio/pci-quirks.c:1356:55: error: ‘IGD_GMCH’ undeclared (first use in this function) + 1356 | uint32_t gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, sizeof(gmch)); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1356:55: note: each undeclared identifier is reported only once for each function it appears in +../hw/vfio/pci-quirks.c:1357:21: error: implicit declaration of function ‘igd_gen’ [-Werror=implicit-function-declaration] + 1357 | int ggms, gen = igd_gen(vdev); + | ^~~~~~~ +../hw/vfio/pci-quirks.c:1357:21: error: nested extern declaration of ‘igd_gen’ [-Werror=nested-externs] +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_data_read’: +../hw/vfio/pci-quirks.c:1384:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1384 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1385:30: error: request for member ‘vdev’ in something not a structure or union + 1385 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1387:8: error: request for member ‘index’ in something not a structure or union + 1387 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_data_write’: +../hw/vfio/pci-quirks.c:1395:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1395 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1396:30: error: request for member ‘vdev’ in something not a structure or union + 1396 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1414:13: error: request for member ‘index’ in something not a structure or union + 1414 | if ((igd->index % 4 == 1) && igd->index < vfio_igd_gtt_max(vdev)) { + | ^~ +../hw/vfio/pci-quirks.c:1414:37: error: request for member ‘index’ in something not a structure or union + 1414 | if ((igd->index % 4 == 1) && igd->index < vfio_igd_gtt_max(vdev)) { + | ^~ +../hw/vfio/pci-quirks.c:1415:28: error: request for member ‘index’ in something not a structure or union + 1415 | if (gen < 8 || (igd->index % 8 == 1)) { + | ^~ +../hw/vfio/pci-quirks.c:1418:53: error: ‘IGD_BDSM’ undeclared (first use in this function) + 1418 | base = pci_get_long(vdev->pdev.config + IGD_BDSM); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1420:17: error: implicit declaration of function ‘hw_error’; did you mean ‘herror’? [-Werror=implicit-function-declaration] + 1420 | hw_error("vfio-igd: Guest attempted to program IGD GTT before " + | ^~~~~~~~ + | herror +../hw/vfio/pci-quirks.c:1420:17: error: nested extern declaration of ‘hw_error’ [-Werror=nested-externs] +../hw/vfio/pci-quirks.c:1424:29: error: request for member ‘bdsm’ in something not a structure or union + 1424 | val = data - igd->bdsm + base; + | ^~ +../hw/vfio/pci-quirks.c:1430:42: error: request for member ‘index’ in something not a structure or union + 1430 | igd->index, data, val); + | ^~ +../hw/vfio/pci-quirks.c:1435:8: error: request for member ‘index’ in something not a structure or union + 1435 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_index_read’: +../hw/vfio/pci-quirks.c:1447:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1447 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1448:30: error: request for member ‘vdev’ in something not a structure or union + 1448 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1450:8: error: request for member ‘index’ in something not a structure or union + 1450 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_index_write’: +../hw/vfio/pci-quirks.c:1458:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1458 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1459:30: error: request for member ‘vdev’ in something not a structure or union + 1459 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1461:8: error: request for member ‘index’ in something not a structure or union + 1461 | igd->index = data; + | ^~ +../hw/vfio/pci-quirks.c: At top level: +../hw/vfio/pci-quirks.c:1472:13: error: static declaration of ‘vfio_probe_igd_bar4_quirk’ follows non-static declaration + 1472 | static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr) + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from ../hw/vfio/pci-quirks.c:27: +../hw/vfio/pci.h:211:6: note: previous declaration of ‘vfio_probe_igd_bar4_quirk’ was here + 211 | void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr); + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/vfio/pci-quirks.c: In function ‘vfio_probe_igd_bar4_quirk’: +../hw/vfio/pci-quirks.c:1477:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1477 | VFIOIGDQuirk *igd; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1511:46: error: ‘IGD_GMCH’ undeclared (first use in this function) + 1511 | gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, 4); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1603:32: error: ‘ERR_PREFIX’ undeclared (first use in this function) + 1603 | error_reportf_err(err, ERR_PREFIX, vdev->vbasedev.name); + | ^~~~~~~~~~ +../hw/vfio/pci-quirks.c:1638:8: error: request for member ‘vdev’ in something not a structure or union + 1638 | igd->vdev = vdev; + | ^~ +../hw/vfio/pci-quirks.c:1639:8: error: request for member ‘index’ in something not a structure or union + 1639 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c:1640:8: error: request for member ‘bdsm’ in something not a structure or union + 1640 | igd->bdsm = vfio_pci_read_config(&vdev->pdev, IGD_BDSM, 4); + | ^~ +../hw/vfio/pci-quirks.c:1640:51: error: ‘IGD_BDSM’ undeclared (first use in this function) + 1640 | igd->bdsm = vfio_pci_read_config(&vdev->pdev, IGD_BDSM, 4); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1641:8: error: request for member ‘bdsm’ in something not a structure or union + 1641 | igd->bdsm &= ~((1 << 20) - 1); /* 1MB aligned */ + | ^~ +cc1: all warnings being treated as errors +[61/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-crypto-pci.c.o +[62/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-crypto.c.o +[63/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user-fs.c.o +[64/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user-fs-pci.c.o +[65/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-vdpa.c.o +[66/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-balloon.c.o +[67/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user.c.o +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:163: run-ninja] Error 1 +make[1]: Leaving directory '/qemu-git/qemu/build' +make: *** [GNUmakefile:11: all] Error 2 +``` +Steps to reproduce: +1. git clone git://git.qemu.org/qemu.git +2. ./configure --prefix=/usr \--target-list=x86_64-softmmu +3. make -j8 diff --git a/results/classifier/accel-gemma3:12b/vmm/961757 b/results/classifier/accel-gemma3:12b/vmm/961757 new file mode 100644 index 000000000..5f694a4bc --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/961757 @@ -0,0 +1,20 @@ + +wrong error for blockdev-snapshot-sync + +From Laszlo Ersek: + +>> + proto_drv = bdrv_find_protocol(snapshot_file); +>> if (!proto_drv) { +>> - qerror_report(QERR_INVALID_BLOCK_FORMAT, format); +>> - ret = -1; +>> - goto out; +>> + error_set(errp, QERR_INVALID_BLOCK_FORMAT, format); +>> + return; +>> } +> +> I don't understand the logic here (based on the error message). We +> specified "format" for the case when a completely new snapshot file has +> to be created. If the file exists already, then bdrv_find_protocol() +> tries to find the driver for it. If that fails, then we must report an +> error indeed, but instead of referring to "format", we'd have to report +> the "scheme" from the beginning of "snapshot_file". \ No newline at end of file diff --git a/results/classifier/accel-gemma3:12b/vmm/965867 b/results/classifier/accel-gemma3:12b/vmm/965867 new file mode 100644 index 000000000..c5fd5e719 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/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/accel-gemma3:12b/vmm/974 b/results/classifier/accel-gemma3:12b/vmm/974 new file mode 100644 index 000000000..d4b1a9a17 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/974 @@ -0,0 +1,4 @@ + +Enable virtio-9pfs on windows hosts +Additional information: +attn: @schoenebeck diff --git a/results/classifier/accel-gemma3:12b/vmm/975 b/results/classifier/accel-gemma3:12b/vmm/975 new file mode 100644 index 000000000..e95f22854 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/975 @@ -0,0 +1,39 @@ + +LXD with QEMU 6.2.0 (and 7.0.0-rc3) breaks during stateful migration +Description of problem: + +Steps to reproduce: +``` +sudo snap install --lxd +sudo lxd init --auto +lxc init images:ubuntu/20.04/cloud v1 --vm +Creating v1 +lxc config device override v1 root size.state=2GiB +Device root overridden for v1 +lxc config set v1 migration.stateful=true +lxc start v1 +sleep 10 +lxc exec v1 -- uptime + 22:05:54 up 0 min, 0 users, load average: 0.07, 0.02, 0.00 +lxc snapshot v1 --stateful +Error: Migration call failed +lxc snapshot v1 --stateful +Error: Monitor is disconnected +``` + +The first attempt at `lxc snapshot v1 --stateful` caused this in the `lxc info v1 --show-log` log output: + +``` +qemu-system-x86_64: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1) +``` + +The second attempt caused this: + +``` +qemu-system-x86_64: ../block.c:6757: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +``` + +Which crashed QEMU completely and caused the VM to die. +Nothing relevant showed up in dmesg, so this wasn't caused by an obvious seccomp or apparmor policy issue. +Additional information: +Originally reported by Stephane Graber at https://github.com/lxc/lxd/issues/9875 diff --git a/results/classifier/accel-gemma3:12b/vmm/977 b/results/classifier/accel-gemma3:12b/vmm/977 new file mode 100644 index 000000000..41a35734f --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/977 @@ -0,0 +1,2 @@ + +QEMU 6.2, windows 98 doesn't shutdown properly diff --git a/results/classifier/accel-gemma3:12b/vmm/981 b/results/classifier/accel-gemma3:12b/vmm/981 new file mode 100644 index 000000000..0f2e910d1 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/981 @@ -0,0 +1,11 @@ + +VNC UNIX sockets are not deleted +Description of problem: +After exiting QEMU a unix VNC socket file is left behind. Upon termination I would expect it to remove the socket file like it does for example with a monitor unix socket. +Steps to reproduce: +``` + rm -f foo.socket + qemu-system-x86_64 -vnc unix:foo.socket + # Exit QEMU + ls foo.socket + ``` diff --git a/results/classifier/accel-gemma3:12b/vmm/983 b/results/classifier/accel-gemma3:12b/vmm/983 new file mode 100644 index 000000000..f29afc357 --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/983 @@ -0,0 +1,9 @@ + +Qemu Wiki Database Query Error +Steps to reproduce: +1. Access the Qemu Wiki. https://wiki.qemu.org/Main_Page +2. Type "serial" in the search bar and hit the enter key. +3. Crash ensues. +Additional information: +Crash info attached. +[qemu_wiki_bug.txt](/uploads/06fb534ea65c486f72dce14e75c834bd/qemu_wiki_bug.txt) diff --git a/results/classifier/accel-gemma3:12b/vmm/986 b/results/classifier/accel-gemma3:12b/vmm/986 new file mode 100644 index 000000000..5825c4a4a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/986 @@ -0,0 +1,40 @@ + +vpc images are created with bigger virtual size than required +Description of problem: +Required virtual size is 895287296, but as qemu-img info reports it is 895426560. +Steps to reproduce: +1. qemu-img create -f vpc img1.vpc 895287296 +2. qemu-img info img1.vpc +Additional information: +Converting back and forth is not possible as a result + ``` +$ qemu-img info openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +image: openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +file format: raw +virtual size: 854 MiB (895287296 bytes) +disk size: 854 MiB + +$ qemu-img create -f vpc img1.vpc 895287296 +Formatting 'img1.vpc', fmt=vpc size=895287296 + +$ qemu-img convert -n \ + -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \ + -O vpc img1.vpc + +$ qemu-img compare \ + -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \ + -F vpc img1.vpc +Warning: Image size mismatch! +Images are identical. + +$ qemu-img create -f raw img2.raw 895287296 +Formatting 'img2.raw', fmt=raw size=895287296 + +$ qemu-img convert -n -f vpc img1.vpc -O raw img2.raw +qemu-img: output file is smaller than input file + +$ qemu-img compare \ + -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \ + -F raw img2.raw +Content mismatch at offset 0! + ``` diff --git a/results/classifier/accel-gemma3:12b/vmm/996 b/results/classifier/accel-gemma3:12b/vmm/996 new file mode 100644 index 000000000..489b75c7c --- /dev/null +++ b/results/classifier/accel-gemma3:12b/vmm/996 @@ -0,0 +1,27 @@ + +Alt-TAB minimizes a full screen key-grabbed SDL window +Description of problem: +I was made aware of a case where a qemu seems to respond to a keyboard event `Alt+Tab` that isn't meant for it. + +When running in "SDL + full-screen + keys being grabbed by the guest" (see steps to reproduce below) one would expect `Alt+Tab` to do nothing on the host. But it does minimize the qemu window. + +This does not happen if: +- using GTK instead of SDL +- not being in full-screen mode + +No error message or warning appears while this happens. +Steps to reproduce: +You do not need and workload to run inside qemu for this + +1. `qemu-system-x86_64 -display sdl` +2. Get your key grabbed: `click inside the window` +3. Go full screen: `Alt+Ctrl+F` +4. Press `Alt+Tab` +5. Expected: nothing, Experienced: window minimizes + +Note: it even is reproducible if running the qemu binary from another system through SSH with X11 forwarding. + +P.S. +I haven't had a chance yet to try qemu 7.0 from git, but will in a bit. +It is easy enough to reproduce that I considered it worth filing without. +For the start it would be great to hear if others see that as well or not. In case of the latter we'd have to compare library versions (currently I use sdl 2.0.20+dfsg-2build1). |