diff options
Diffstat (limited to 'results/classifier/gemma3:12b/device')
950 files changed, 27067 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/device/1006 b/results/classifier/gemma3:12b/device/1006 new file mode 100644 index 000000000..6426578fc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1006 @@ -0,0 +1,4 @@ + +qga: add get disk stats of guest interface +Additional information: +just for linux diff --git a/results/classifier/gemma3:12b/device/1013691 b/results/classifier/gemma3:12b/device/1013691 new file mode 100644 index 000000000..6f4668f91 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1013691 @@ -0,0 +1,15 @@ + +ppc64 + virtio-scsi: only first scsi disk shows up in the guest + +When adding two virtio-scsi targets to a single guest, only the first +disk is seen inside the guest. For some unknown reason the guest +doesn't enumerate the second disk. + +For full qemu-system-ppc64 command line and 'dmesg' output, see: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02430.html + +I have also tried this with Linus's git tree (3.5.0-rc2+ at time of writing), +same thing. + +In both cases I'm using qemu from git. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1014099 b/results/classifier/gemma3:12b/device/1014099 new file mode 100644 index 000000000..98979f070 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1014099 @@ -0,0 +1,8 @@ + +hw/esp.c does not properly deal with TEST_UNIT_READY in NetBSD/sparc + +The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN but dma disabled sometimes (early during bus enumeration). This is fine, as the command will not produce nor consume any data, and works on real hardware. + +However, the qemu emulation does not allow this (for reasons I don't understand). + +The change below fixes the problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1015 b/results/classifier/gemma3:12b/device/1015 new file mode 100644 index 000000000..be3717b13 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1015 @@ -0,0 +1,2 @@ + +qemu-7.0 there is no device "hostdev0" defined diff --git a/results/classifier/gemma3:12b/device/1017793 b/results/classifier/gemma3:12b/device/1017793 new file mode 100644 index 000000000..7a8496ea0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1017793 @@ -0,0 +1,6 @@ + +S3 Trio64V+ support + +Is it possible to add S3 Trio emulation to QEMU at all? Since 0.12.3 the Cirrus Logic seems no longer working properly (bad font render/corrupted video). Also, S3 is a widely supported device on many OSes and architectures, which will give more compatibility for QEMU. + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1024 b/results/classifier/gemma3:12b/device/1024 new file mode 100644 index 000000000..f42623c85 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1024 @@ -0,0 +1,11 @@ + +Unable to build QEMU with dbus display support on Windows +Description of problem: +When building QEMU on Windows with `./configure --enable-dbus-display --enable-modules`, the following error appears: + +`ERROR: Modules are not available for Windows` +Steps to reproduce: +1. Attempt to build QEMU on Windows (MSYS2 MinGW) with dbus display support +Additional information: +Attempting to build with only `--enable-dbus-display` does not work either, as it requires `--enable-modules`, which does not work on Windows: +`../meson.build:1598:0: ERROR: Feature dbus_display cannot be enabled: -display dbus requires --enable-modules` diff --git a/results/classifier/gemma3:12b/device/1024275 b/results/classifier/gemma3:12b/device/1024275 new file mode 100644 index 000000000..953839683 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1024275 @@ -0,0 +1,13 @@ + +bad iteraction between -daemonize and -nographic + + $ qemu -daemonize -nographic + $ _ + +After this, the terminal is switched to some weird mode, not processing cr/lf, and not showing the characters being typed (it is fixable by using `stty sane'). + +Something is seriously wrong here: When -daemonize is given, qemu not touch tty parameters at all. + +Thanks, + +/mjt \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1030 b/results/classifier/gemma3:12b/device/1030 new file mode 100644 index 000000000..112d9e6f2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1030 @@ -0,0 +1,2 @@ + +Property 'rv32-riscv-cpu.x-v' not found diff --git a/results/classifier/gemma3:12b/device/1030807 b/results/classifier/gemma3:12b/device/1030807 new file mode 100644 index 000000000..76cb50ec6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1030807 @@ -0,0 +1,35 @@ + +PCI host bridge should ignore 1- and 2-byte I/O accesses + +In PCI there are two IO modes. Deprecated Mode2 that uses single byte IO and Mode1 that uses 4byte IO. +According to the spec a host bridge that supports Mode1 should ignore all IO that is not 4bytes. + +> Anytime a host bridge sees a full DWORD I/O write from the host to +> CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS +> register. On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return the +> data in CONFIG_ADDRESS. Any other types of accesses to this address (non-DWORD) +> have no effect on CONFIG_ADDRESS and are executed as normal I/O transactions on +> the PCI bus. Therefore, the only I/O Space consumed by this register is a DWORD at the +> given address. I/O devices that share the same address but use BYTE or WORD registers +> are not affected because their transactions will pass through the host bridge unchanged. + +In qemu the host bridge will accept 1-, 2-, and 4-byte reads/writes. That breakes plan9 guests that do not use the bios to access the PCI config space. + +have a look at: +http://code.google.com/p/plan9front/source/browse/sys/src/9/pc/pci.c + +In Lines 960-967 the check for PCI Mode1 is done. This check assumes that the 4-byte write at line 961 succeeds and the single byte write at 962 is ignored. +On qemu line 962 will not be ignored and the test in line 963 will fail. +The plan9 kernel will fall back to Mode2 which does not work. +The result is that the guest will not see any PCI devices. + +I do not really have an image that you guys could quickly check this with, but i could prepare one if need be. +An easy way to reproduce this in linux would be to stick an outb between those two lines from pci_check_type1(void). + +> outl(0x80000000, 0xCF8); ++ outb0x01, 0xcfb); +> if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) { + +I did not try this but i guess on real hardware the linux kernel would still work while it would not work anymore on qemu. + +I tried to come up with a patch but did not find a quick solution. I found that in hw/piic_pci.c sysbus_add_io is used which will register read/write functions for 1, 2, and 4 bytes. This is done in ioport.c ioport_register. I guess if i provided a patch you guys might not like it :). So i figured i should report the bug, let me know if you need any additional information. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1034980 b/results/classifier/gemma3:12b/device/1034980 new file mode 100644 index 000000000..4836c6cc4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1034980 @@ -0,0 +1,18 @@ + +pseries machine: vscsi scsi qemu cd-rom does not work in win32 + +On Win32, the cd-rom device is not detected at all in the pseries machine (SLOF): + + qemu-system-ppc64 -M pseries -m 512 -cdrom img.iso + ....etc. + VSCSI: Looking for disks + Populating /pci@800000020000001,0 + + +On Linux however, the scsi qemu cd-rom device is detected and works fine in the pseries machine: + + qemu-system-ppc64 -M pseries -m 512 -cdrom img.iso + ....etc. + VSCSI: Looking for disks + SCSI ID 2 CD-ROM : "QEMU QEMU CD-ROM 1.1." + Populating /pci@800000020000001,0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1038070 b/results/classifier/gemma3:12b/device/1038070 new file mode 100644 index 000000000..d7b0af808 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1038070 @@ -0,0 +1,28 @@ + +> qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore + +Linux Distro: Gentoo + +Smartcard Activkey doesn't work anymore. I use it without problem till version +qemu-kvm-1.0.1. + +Follow a log extraction: +2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +If you need any other info please tell me. + +I've tried with git version with same problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1047999 b/results/classifier/gemma3:12b/device/1047999 new file mode 100644 index 000000000..0d4fc8c4a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1047999 @@ -0,0 +1,89 @@ + +error building process in sdlaudio.o + +./configure --enable-sdl --enable-virtfs --enable-vnc --enable-cocoa --enable-mixemu --enable-brlapi --enable-vnc-tls --enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --enable-curses --enable-curl --enable-bluez --enable-tcg-interpreter --enable-nptl --enable-system --enable-user --enable-linux-user --enable-guest-base --enable-pie --enable-uuid --enable-vde --enable-attr --enable-docs --enable-vhost-net --enable-smartcard --enable-guest-agent --enable-seccomp --audio-drv-list="alsa oss sdl esd pa" --audio-card-list="ac97 es1370 sb16 cs4231a adlib gus hda" --prefix=/opt/qemu + +audio/sdlaudio.c:55: error: expected specifier-qualifier-list before ‘SDL_mutex’ +audio/sdlaudio.c: In function ‘sdl_logerr’: +audio/sdlaudio.c:69: warning: implicit declaration of function ‘SDL_GetError’ +audio/sdlaudio.c:69: warning: nested extern declaration of ‘SDL_GetError’ +audio/sdlaudio.c:69: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’ +audio/sdlaudio.c: In function ‘sdl_lock’: +audio/sdlaudio.c:74: warning: implicit declaration of function ‘SDL_LockMutex’ +audio/sdlaudio.c:74: warning: nested extern declaration of ‘SDL_LockMutex’ +audio/sdlaudio.c:74: error: ‘SDLAudioState’ has no member named ‘mutex’ +audio/sdlaudio.c: In function ‘sdl_unlock’: +audio/sdlaudio.c:83: warning: implicit declaration of function ‘SDL_UnlockMutex’ +audio/sdlaudio.c:83: warning: nested extern declaration of ‘SDL_UnlockMutex’ +audio/sdlaudio.c:83: error: ‘SDLAudioState’ has no member named ‘mutex’ +audio/sdlaudio.c: In function ‘sdl_post’: +audio/sdlaudio.c:92: warning: implicit declaration of function ‘SDL_SemPost’ +audio/sdlaudio.c:92: warning: nested extern declaration of ‘SDL_SemPost’ +audio/sdlaudio.c:92: error: ‘SDLAudioState’ has no member named ‘sem’ +audio/sdlaudio.c: In function ‘sdl_wait’: +audio/sdlaudio.c:101: warning: implicit declaration of function ‘SDL_SemWait’ +audio/sdlaudio.c:101: warning: nested extern declaration of ‘SDL_SemWait’ +audio/sdlaudio.c:101: error: ‘SDLAudioState’ has no member named ‘sem’ +audio/sdlaudio.c: In function ‘aud_to_sdlfmt’: +audio/sdlaudio.c:121: error: ‘AUDIO_S8’ undeclared (first use in this function) +audio/sdlaudio.c:121: error: (Each undeclared identifier is reported only once +audio/sdlaudio.c:121: error: for each function it appears in.) +audio/sdlaudio.c:124: error: ‘AUDIO_U8’ undeclared (first use in this function) +audio/sdlaudio.c:127: error: ‘AUDIO_S16LSB’ undeclared (first use in this function) +audio/sdlaudio.c:130: error: ‘AUDIO_U16LSB’ undeclared (first use in this function) +audio/sdlaudio.c: In function ‘sdl_to_audfmt’: +audio/sdlaudio.c:144: error: ‘AUDIO_S8’ undeclared (first use in this function) +audio/sdlaudio.c:149: error: ‘AUDIO_U8’ undeclared (first use in this function) +audio/sdlaudio.c:154: error: ‘AUDIO_S16LSB’ undeclared (first use in this function) +audio/sdlaudio.c:159: error: ‘AUDIO_U16LSB’ undeclared (first use in this function) +audio/sdlaudio.c:164: error: ‘AUDIO_S16MSB’ undeclared (first use in this function) +audio/sdlaudio.c:169: error: ‘AUDIO_U16MSB’ undeclared (first use in this function) +audio/sdlaudio.c: At top level: +audio/sdlaudio.c:182: error: expected ‘)’ before ‘*’ token +audio/sdlaudio.c: In function ‘sdl_close’: +audio/sdlaudio.c:222: error: ‘SDLAudioState’ has no member named ‘initialized’ +audio/sdlaudio.c:226: warning: implicit declaration of function ‘SDL_PauseAudio’ +audio/sdlaudio.c:226: warning: nested extern declaration of ‘SDL_PauseAudio’ +audio/sdlaudio.c:227: warning: implicit declaration of function ‘SDL_CloseAudio’ +audio/sdlaudio.c:227: warning: nested extern declaration of ‘SDL_CloseAudio’ +audio/sdlaudio.c:228: error: ‘SDLAudioState’ has no member named ‘initialized’ +audio/sdlaudio.c: At top level: +audio/sdlaudio.c:232: error: expected declaration specifiers or ‘...’ before ‘Uint8’ +audio/sdlaudio.c: In function ‘sdl_callback’: +audio/sdlaudio.c:274: error: ‘buf’ undeclared (first use in this function) +audio/sdlaudio.c: In function ‘sdl_init_out’: +audio/sdlaudio.c:339: error: ‘SDL_AudioSpec’ undeclared (first use in this function) +audio/sdlaudio.c:339: error: expected ‘;’ before ‘req’ +audio/sdlaudio.c:345: error: ‘req’ undeclared (first use in this function) +audio/sdlaudio.c:352: warning: implicit declaration of function ‘sdl_open’ +audio/sdlaudio.c:352: warning: nested extern declaration of ‘sdl_open’ +audio/sdlaudio.c:352: error: ‘obt’ undeclared (first use in this function) +audio/sdlaudio.c:370: error: ‘SDLAudioState’ has no member named ‘initialized’ +audio/sdlaudio.c: In function ‘sdl_audio_init’: +audio/sdlaudio.c:396: warning: implicit declaration of function ‘SDL_InitSubSystem’ +audio/sdlaudio.c:396: warning: nested extern declaration of ‘SDL_InitSubSystem’ +audio/sdlaudio.c:396: error: ‘SDL_INIT_AUDIO’ undeclared (first use in this function) +audio/sdlaudio.c:401: error: ‘SDLAudioState’ has no member named ‘mutex’ +audio/sdlaudio.c:401: warning: implicit declaration of function ‘SDL_CreateMutex’ +audio/sdlaudio.c:401: warning: nested extern declaration of ‘SDL_CreateMutex’ +audio/sdlaudio.c:402: error: ‘SDLAudioState’ has no member named ‘mutex’ +audio/sdlaudio.c:404: warning: implicit declaration of function ‘SDL_QuitSubSystem’ +audio/sdlaudio.c:404: warning: nested extern declaration of ‘SDL_QuitSubSystem’ +audio/sdlaudio.c:408: error: ‘SDLAudioState’ has no member named ‘sem’ +audio/sdlaudio.c:408: warning: implicit declaration of function ‘SDL_CreateSemaphore’ +audio/sdlaudio.c:408: warning: nested extern declaration of ‘SDL_CreateSemaphore’ +audio/sdlaudio.c:409: error: ‘SDLAudioState’ has no member named ‘sem’ +audio/sdlaudio.c:411: warning: implicit declaration of function ‘SDL_DestroyMutex’ +audio/sdlaudio.c:411: warning: nested extern declaration of ‘SDL_DestroyMutex’ +audio/sdlaudio.c:411: error: ‘SDLAudioState’ has no member named ‘mutex’ +audio/sdlaudio.c: In function ‘sdl_audio_fini’: +audio/sdlaudio.c:423: warning: implicit declaration of function ‘SDL_DestroySemaphore’ +audio/sdlaudio.c:423: warning: nested extern declaration of ‘SDL_DestroySemaphore’ +audio/sdlaudio.c:423: error: ‘SDLAudioState’ has no member named ‘sem’ +audio/sdlaudio.c:424: error: ‘SDLAudioState’ has no member named ‘mutex’ +audio/sdlaudio.c:425: error: ‘SDL_INIT_AUDIO’ undeclared (first use in this function) +make: *** [audio/sdlaudio.o] Error 1 + +System: +Linux insanelive 3.5.3-iatom-bfq #3 SMP Sat Sep 1 20:30:22 MSK 2012 i686 GNU/Linux +Debian 6.0.5 Squeeze \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1049 b/results/classifier/gemma3:12b/device/1049 new file mode 100644 index 000000000..ede7a14e0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1049 @@ -0,0 +1,2 @@ + +Have DeviceRealize return boolean indicating error diff --git a/results/classifier/gemma3:12b/device/1050 b/results/classifier/gemma3:12b/device/1050 new file mode 100644 index 000000000..b40c9ba2b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1054812 b/results/classifier/gemma3:12b/device/1054812 new file mode 100644 index 000000000..bc5cb99d8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1054812 @@ -0,0 +1,6 @@ + +Configure uses wrong libtool on Darwin + +On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. + +This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1060928 b/results/classifier/gemma3:12b/device/1060928 new file mode 100644 index 000000000..f4e464f62 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1060928 @@ -0,0 +1,292 @@ + +Error in launch virtual server port + +.- configure +.- uname -a +.- script bash launcher +.- Error +.- output serial.c in statusRUN + +----------------------------------- + +.- configure + +./configure --target-list=i386-softmmu,x86_64-softmmu,\ +i386-linux-user,x86_64-linux-user --enable-vde --disable-vnc --enable-sdl \ +--audio-drv-list=oss,alsa,sdl,esd,pa \ +--audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda &>status + +----------------------------------- + +.- uname -a +Linux Aspire5250 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +----------------------------------- + +.- script bash launcher + +#!/bin/bash + +qemu-system-i386 -m 128 -display sdl -cpu pentium \ +-k es \ +-net nic,vlan=0,macaddr=52:54:00:12:02:04,model=pcnet \ +-net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ +-serial unix:/tmp/com1,server,nowait \ +-vga cirrus \ +-boot c -hda "/home/VirtualMachines/Discos/Hispa70_1.vmdk" \ +-cdrom "/home/VirtualMachines/CDROM/hf-7.0a.iso" 2>statusRUN + +echo -n "Pulsa enter para continuar . . . " && read REPLY + +----------------------------------- + +.- Error + +*** buffer overflow detected ***: qemu-system-i386 terminated +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2759892007] +/lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7f2759890f00] +/lib/x86_64-linux-gnu/libc.so.6(+0x108fbe)[0x7f2759891fbe] +qemu-system-i386(+0xe5153)[0x7f275bfd8153] +qemu-system-i386(+0x1744f6)[0x7f275c0674f6] +qemu-system-i386(main+0xe77)[0x7f275bf5ef37] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f27597aa76d] +qemu-system-i386(+0x70229)[0x7f275bf63229] +======= Memory map: ======== +41912000-43912000 rwxp 00000000 00:00 0 +7f2730000000-7f2730054000 rw-p 00000000 00:00 0 +7f2730054000-7f2734000000 ---p 00000000 00:00 0 +7f2736539000-7f273bdff000 r--p 00000000 08:05 1978631 /usr/lib/locale/locale-archive +7f273bdff000-7f273be00000 rw-p 00000000 00:00 0 +7f273be00000-7f2743e00000 rw-p 00000000 00:00 0 +7f2743e00000-7f2744000000 rw-p 00000000 00:00 0 +7f2744000000-7f2744021000 rw-p 00000000 00:00 0 +7f2744021000-7f2748000000 ---p 00000000 00:00 0 +7f274c000000-7f274c021000 rw-p 00000000 00:00 0 +7f274c021000-7f2750000000 ---p 00000000 00:00 0 +7f27500c5000-7f27500ca000 r-xp 00000000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27500ca000-7f27502c9000 ---p 00005000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27502c9000-7f27502ca000 r--p 00004000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27502ca000-7f27502cb000 rw-p 00005000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27502cb000-7f27502d4000 r-xp 00000000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27502d4000-7f27504d3000 ---p 00009000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27504d3000-7f27504d4000 r--p 00008000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27504d4000-7f27504d5000 rw-p 00009000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27504d5000-7f27504de000 r-xp 00000000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27504de000-7f27506dd000 ---p 00009000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27506dd000-7f27506de000 r--p 00008000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27506de000-7f27506df000 rw-p 00009000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27506df000-7f2750763000 rw-p 00000000 00:00 0 +7f2750775000-7f2750776000 rw-p 00000000 00:00 0 +7f2750776000-7f2750890000 rw-s 00000000 00:04 1736706 /SYSV00000000 (deleted) +7f2750890000-7f2750a00000 rw-p 00000000 00:00 0 +7f2750a00000-7f2751200000 rw-p 00000000 00:00 0 +7f2751200000-7f2751291000 rw-p 00000000 00:00 0 +7f2751291000-7f2751292000 ---p 00000000 00:00 0 +7f2751292000-7f2751a92000 rw-p 00000000 00:00 0 +7f2751a92000-7f2751a93000 ---p 00000000 00:00 0 +7f2751a93000-7f2752293000 rw-p 00000000 00:00 0 +7f2752293000-7f2752294000 ---p 00000000 00:00 0 +7f2752294000-7f2752a94000 rw-p 00000000 00:00 0 +7f2752a94000-7f2752a95000 ---p 00000000 00:00 0 +7f2752a95000-7f2753295000 rw-p 00000000 00:00 0 +7f2753295000-7f2753296000 ---p 00000000 00:00 0 +7f2753296000-7f2753a96000 rw-p 00000000 00:00 0 +7f2753a96000-7f2753aa2000 r-xp 00000000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753aa2000-7f2753ca1000 ---p 0000c000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753ca1000-7f2753ca2000 r--p 0000b000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753ca2000-7f2753ca3000 rw-p 0000c000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753ca3000-7f2753cad000 r-xp 00000000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753cad000-7f2753ead000 ---p 0000a000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753ead000-7f2753eae000 r--p 0000a000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753eae000-7f2753eaf000 rw-p 0000b000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753eaf000-7f2753eb7000 r-xp 00000000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f2753eb7000-7f27540b6000 ---p 00008000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f27540b6000-7f27540b7000 r--p 00007000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f27540b7000-7f27540b8000 rw-p 00008000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f27540b8000-7f2755cb9000 rw-p 00000000 00:00 0 +7f2755cb9000-7f2755cce000 r-xp 00000000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755cce000-7f2755ecd000 ---p 00015000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755ecd000-7f2755ece000 r--p 00014000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755ece000-7f2755ecf000 rw-p 00015000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755ecf000-7f2755ee7000 r-xp 00000000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f2755ee7000-7f27560e7000 ---p 00018000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f27560e7000-7f27560e8000 r--p 00018000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f27560e8000-7f27560e9000 rw-p 00019000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f27560e9000-7f27560eb000 rw-p 00000000 00:00 0 +7f27560eb000-7f27560f1000 r-xp 00000000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27560f1000-7f27562f0000 ---p 00006000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27562f0000-7f27562f1000 r--p 00005000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27562f1000-7f27562f2000 rw-p 00006000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27562f2000-7f275631d000 r-xp 00000000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275631d000-7f275651c000 ---p 0002b000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275651c000-7f275651d000 r--p 0002a000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275651d000-7f275651e000 rw-p 0002b000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275651e000-7f27567d1000 r-xp 00000000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27567d1000-7f27569d0000 ---p 002b3000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27569d0000-7f27569ec000 r--p 002b2000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27569ec000-7f27569ed000 rw-p 002ce000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27569ed000-7f2756a35000 r-xp 00000000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756a35000-7f2756c35000 ---p 00048000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756c35000-7f2756c36000 r--p 00048000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756c36000-7f2756c37000 rw-p 00049000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756c37000-7f2756c4e000 r-xp 00000000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756c4e000-7f2756e4d000 ---p 00017000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756e4d000-7f2756e4e000 r--p 00016000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756e4e000-7f2756e4f000 rw-p 00017000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756e4f000-7f2756e51000 rw-p 00000000 00:00 0 +7f2756e51000-7f2756e56000 r-xp 00000000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2756e56000-7f2757055000 ---p 00005000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2757055000-7f2757056000 r--p 00004000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2757056000-7f2757057000 rw-p 00005000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2757057000-7f2757059000 r-xp 00000000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f2757059000-7f2757258000 ---p 00002000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f2757258000-7f2757259000 r--p 00001000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f2757259000-7f275725a000 rw-p 00002000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f275725a000-7f2757286000 r-xp 00000000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757286000-7f2757485000 ---p 0002c000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757485000-7f2757486000 r--p 0002b000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757486000-7f2757487000 rw-p 0002c000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757487000-7f2757578000 r-xp 00000000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f2757578000-7f2757778000 ---p 000f1000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f2757778000-7f275777c000 r--p 000f1000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f275777c000-7f2757794000 rw-p 000f5000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f2757794000-7f27577f8000 rw-p 00000000 00:00 0 +7f27577f8000-7f27578da000 r-xp 00000000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f27578da000-7f2757ad9000 ---p 000e2000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f2757ad9000-7f2757ae1000 r--p 000e1000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f2757ae1000-7f2757ae3000 rw-p 000e9000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f2757ae3000-7f2757af8000 rw-p 00000000 00:00 0 +7f2757af8000-7f2757afd000 r-xp 00000000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757afd000-7f2757cfc000 ---p 00005000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757cfc000-7f2757cfd000 r--p 00004000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757cfd000-7f2757cfe000 rw-p 00005000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757cfe000-7f2757d5e000 r-xp 00000000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757d5e000-7f2757f5e000 ---p 00060000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757f5e000-7f2757f60000 r--p 00060000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757f60000-7f2757f61000 rw-p 00062000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757f61000-7f2757f65000 rw-p 00000000 00:00 0 +7f2757f65000-7f2757f6d000 r-xp 00000000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f2757f6d000-7f275816c000 ---p 00008000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f275816c000-7f275816d000 r--p 00007000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f275816d000-7f275816e000 rw-p 00008000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f275816e000-7f275818b000 r-xp 00000000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275818b000-7f275838a000 ---p 0001d000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275838a000-7f275838b000 r--p 0001c000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275838b000-7f275838c000 rw-p 0001d000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275838c000-7f27583ae000 r-xp 00000000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f27583ae000-7f27585ae000 ---p 00022000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f27585ae000-7f27585af000 r--p 00022000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f27585af000-7f2758652000 rw-p 00023000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f2758652000-7f2758657000 rw-p 00000000 00:00 0 +7f2758657000-7f2758667000 r-xp 00000000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758667000-7f2758866000 ---p 00010000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758866000-7f2758867000 r--p 0000f000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758867000-7f2758868000 rw-p 00010000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758868000-7f275886b000 r-xp 00000000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f275886b000-7f2758a6a000 ---p 00003000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f2758a6a000-7f2758a6b000 r--p 00002000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f2758a6b000-7f2758a6c000 rw-p 00003000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f2758a6c000-7f2758a9b000 r-xp 00000000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758a9b000-7f2758c9b000 ---p 0002f000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758c9b000-7f2758c9d000 r--p 0002f000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758c9d000-7f2758c9e000 rw-p 00031000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758c9e000-7f2758ce0000 r-xp 00000000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ce0000-7f2758ee0000 ---p 00042000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ee0000-7f2758ee1000 r--p 00042000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ee1000-7f2758ee2000 rw-p 00043000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ee2000-7f2758f3e000 r-xp 00000000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f2758f3e000-7f275913e000 ---p 0005c000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f275913e000-7f275913f000 r--p 0005c000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f275913f000-7f2759140000 rw-p 0005d000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f2759140000-7f2759147000 r-xp 00000000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1 +7f2759147000-7f2759346000 ---p 00007000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1 +7f2759346000-7f2759347000 r--p 00006000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1 +7f2759347000-7f2759348000 rw-p 00007000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1./RUN_HISPA_1: línea 17: 2952 Abortado (`core' generado) qemu-system-i386 -m 128 -display sdl -cpu pentium -k es -net nic,vlan=0,macaddr=52:54:00:12:02:04,model=pcnet -net vde,vlan=0,sock=/var/run/vde2/tap0.ctl -serial unix:/tmp/com1,server,nowait -vga cirrus -boot c -hda "/home/VirtualMachines/Discos/Hispa70_1.vmdk" -cdrom "/home/VirtualMachines/CDROM/hf-7.0a.iso" 2> statusRUN + +----------------------------------- + +.- output serial.c in statusRUN + +serial: write addr=0x01 val=0x02 +serial: read addr=0x01 val=0x02 +serial: read addr=0x02 val=0x02 +serial: write addr=0x01 val=0x00 +serial: read addr=0x01 val=0x00 +serial: write addr=0x01 val=0x00 +serial: read addr=0x01 val=0x00 +serial: write addr=0x01 val=0x00 +serial: read addr=0x03 val=0x00 +serial: write addr=0x03 val=0xbf +serial: speed=9600 parity=E data=8 stop=2 +serial: write addr=0x02 val=0x00 +serial: write addr=0x03 val=0x00 +serial: speed=9600 parity=N data=5 stop=1 +serial: write addr=0x02 val=0x01 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x03 val=0x80 +serial: speed=9600 parity=N data=5 stop=1 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x03 val=0xbf +serial: speed=9600 parity=E data=8 stop=2 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x03 val=0x80 +serial: speed=9600 parity=N data=5 stop=1 +serial: write addr=0x02 val=0x21 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x02 val=0x01 +serial: write addr=0x03 val=0x00 +serial: speed=9600 parity=N data=5 stop=1 +serial: write addr=0x04 val=0x00 +serial: write addr=0x02 val=0x06 +serial: read addr=0x00 val=0x00 +serial: write addr=0x01 val=0x00 +serial: write addr=0x02 val=0x06 +serial: read addr=0x05 val=0x60 +serial: read addr=0x00 val=0x00 +serial: read addr=0x02 val=0x01 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x03 val=0x03 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x04 val=0x0b +serial: write addr=0x01 val=0x0d +serial: read addr=0x05 val=0x60 +serial: read addr=0x00 val=0x00 +serial: read addr=0x02 val=0x01 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x01 val=0x05 +serial: write addr=0x03 val=0x93 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x00 val=0x0c +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x01 val=0x00 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x03 val=0x13 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x02 val=0x01 +serial: write addr=0x02 val=0x81 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x04 val=0x09 +serial: read addr=0x05 val=0x60 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x01 val=0x05 +serial: read addr=0x02 val=0xc1 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x01 val=0x05 +serial: write addr=0x03 val=0x96 +serial: speed=9600 parity=N data=7 stop=2 +serial: write addr=0x00 val=0x60 +serial: speed=1200 parity=N data=7 stop=2 +serial: write addr=0x01 val=0x00 +serial: speed=1200 parity=N data=7 stop=2 +serial: write addr=0x03 val=0x16 +serial: speed=1200 parity=N data=7 stop=2 +serial: write addr=0x02 val=0x01 +serial: write addr=0x02 val=0x01 +serial: write addr=0x04 val=0x08 +serial: write addr=0x04 val=0x09 +serial: write addr=0x04 val=0x0b +serial: write addr=0x01 val=0x07 +serial: read addr=0x05 val=0x60 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x00 val=0x41 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1067119 b/results/classifier/gemma3:12b/device/1067119 new file mode 100644 index 000000000..1dcccbc90 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1067119 @@ -0,0 +1,10 @@ + +e1000 missing statistics + +The E1000 emulation is missing several counters that are used by other software. + +The following would be useful: + Good bytes receive counter GORCH/GORCL + Good bytes transmit counter GOTCH/GOTCL +Broadcast packets sent/received +Multicast packets sent/received. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1070762 b/results/classifier/gemma3:12b/device/1070762 new file mode 100644 index 000000000..46c7d6221 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1076 b/results/classifier/gemma3:12b/device/1076 new file mode 100644 index 000000000..0dc6f6da1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1077708 b/results/classifier/gemma3:12b/device/1077708 new file mode 100644 index 000000000..5aeafd5a3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1077708 @@ -0,0 +1,17 @@ + +Video capture from webcam with USB passthrough freezes + +QEMU version: 1.2.0 +Graphics: Spice +Guest: Windows 7 32-bit +Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) + +I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. + +The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. + +I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. + +Command line: + +/usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -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=/data/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1077838 b/results/classifier/gemma3:12b/device/1077838 new file mode 100644 index 000000000..2655ad110 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1077838 @@ -0,0 +1,31 @@ + +qemu-nbd -r -c taints device for subsequent usage, even after -d + +Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind - subsequent connections get marked readonly. + +This is on quantal, haven't checked precise or raring. + +To demonstrate: +# use one image +qemu-img create -f qcow2 /tmp/1.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +sudo qemu-nbd -d /dev/nbd2 +# use a second one on the same nbd device, shows that reuse works: +qemu-img create -f qcow2 /tmp/2.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +sudo qemu-nbd -d /dev/nbd2 +# connect an image in read only mode +sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2 +sudo dumpe2fs /dev/nbd2 | head -n 3 +sudo qemu-nbd -d /dev/nbd2 +# now try to reuse in read-write mode again: +qemu-img create -f qcow2 /tmp/3.qcow2 100M +sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2 +sudo mkfs -t ext4 /dev/nbd2 +# here it goes boom: +mke2fs 1.42.5 (29-Jul-2012) +/dev/nbd2: Operation not permitted while setting up superblock +# still need to cleanup +sudo qemu-nbd -d /dev/nbd2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/108 b/results/classifier/gemma3:12b/device/108 new file mode 100644 index 000000000..724c90254 --- /dev/null +++ b/results/classifier/gemma3:12b/device/108 @@ -0,0 +1,2 @@ + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 diff --git a/results/classifier/gemma3:12b/device/1080086 b/results/classifier/gemma3:12b/device/1080086 new file mode 100644 index 000000000..6a8ab7831 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1080086 @@ -0,0 +1,25 @@ + +MC146818 RTC breaks when SET bit in Register B is on. + +This bug occurs when the SET flag of Register B is enabled. When an RTC +data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set, +the data is (as expected) correctly stored in the cmos_data array. However, +since the SET flag is enabled, the function rtc_set_time is not invoked. +As a result, the field base_rtc in RTCState remains uninitialized. This appears to +cause a problem on subsequent writes which can end up overwriting data. + +To see this, consider writing data to Register A after having written +data to any of the RTC data registers; the following figure illustrates +the call stack for the Register A write operation: + + +- cmos_io_port_write + +-- check_update_timer + +---- get_next_alarm + +------ rtc_update_time + +In rtc_update_time, get_guest_rtc calculates the wrong time and +overwrites the previously written RTC data register values. + +I have created a standalone test case which exposes this bug: + + https://github.com/ahorn/benchmarks/commit/fff1ca40694bbef6f7f9de323bb0bed63419ef99 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1082 b/results/classifier/gemma3:12b/device/1082 new file mode 100644 index 000000000..c134d24df --- /dev/null +++ b/results/classifier/gemma3:12b/device/1082 @@ -0,0 +1,93 @@ + +Unable to compile QEMU in Ubuntu 22.04 LTS - libcommon.fa.p +Description of problem: +Since a couple of months ago I can not compile QEMU from its official GIT location anymore. +I do everything described in the guide: https://wiki.qemu.org/Hosts/Linux + +After the configure, the building resturn me this issue: +``` +1155/9661] Compiling C object libcommon.fa.p/ui_vdagent.c.o +FAILED: libcommon.fa.p/ui_vdagent.c.o +cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -I../slirp -I../slirp/src -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/local/include/spice-1 -I/usr/include/p11-kit-1 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/vte-2.91 -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/andrea/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/andrea/qemu -iquote /home/andrea/qemu/include -iquote /home/andrea/qemu/disas/libvixl -iquote /home/andrea/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 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -MD -MQ libcommon.fa.p/ui_vdagent.c.o -MF libcommon.fa.p/ui_vdagent.c.o.d -o libcommon.fa.p/ui_vdagent.c.o -c ../ui/vdagent.c +../ui/vdagent.c:82:6: error: ‘VD_AGENT_CAP_SPARSE_MONITORS_CONFIG’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_MONITORS_CONFIG’? + 82 | [VD_AGENT_CAP_SPARSE_MONITORS_CONFIG] = "sparse-monitors-config", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_MONITORS_CONFIG +../ui/vdagent.c:82:6: error: array index in initializer not of integer type +../ui/vdagent.c:82:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:83:6: error: ‘VD_AGENT_CAP_GUEST_LINEEND_LF’ undeclared here (not in a function) + 83 | [VD_AGENT_CAP_GUEST_LINEEND_LF] = "guest-lineend-lf", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:83:6: error: array index in initializer not of integer type +../ui/vdagent.c:83:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:84:6: error: ‘VD_AGENT_CAP_GUEST_LINEEND_CRLF’ undeclared here (not in a function) + 84 | [VD_AGENT_CAP_GUEST_LINEEND_CRLF] = "guest-lineend-crlf", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:84:6: error: array index in initializer not of integer type +../ui/vdagent.c:84:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:85:6: error: ‘VD_AGENT_CAP_MAX_CLIPBOARD’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_CLIPBOARD’? + 85 | [VD_AGENT_CAP_MAX_CLIPBOARD] = "max-clipboard", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_CLIPBOARD +../ui/vdagent.c:85:6: error: array index in initializer not of integer type +../ui/vdagent.c:85:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:86:6: error: ‘VD_AGENT_CAP_AUDIO_VOLUME_SYNC’ undeclared here (not in a function) + 86 | [VD_AGENT_CAP_AUDIO_VOLUME_SYNC] = "audio-volume-sync", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:86:6: error: array index in initializer not of integer type +../ui/vdagent.c:86:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:87:6: error: ‘VD_AGENT_CAP_MONITORS_CONFIG_POSITION’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_MONITORS_CONFIG’? + 87 | [VD_AGENT_CAP_MONITORS_CONFIG_POSITION] = "monitors-config-position", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_MONITORS_CONFIG +../ui/vdagent.c:87:6: error: array index in initializer not of integer type +../ui/vdagent.c:87:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:88:6: error: ‘VD_AGENT_CAP_FILE_XFER_DISABLED’ undeclared here (not in a function) + 88 | [VD_AGENT_CAP_FILE_XFER_DISABLED] = "file-xfer-disabled", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:88:6: error: array index in initializer not of integer type +../ui/vdagent.c:88:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:89:6: error: ‘VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS’ undeclared here (not in a function) + 89 | [VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS] = "file-xfer-detailed-errors", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:89:6: error: array index in initializer not of integer type +../ui/vdagent.c:89:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:109:6: error: ‘VD_AGENT_FILE_XFER_START’ undeclared here (not in a function) + 109 | [VD_AGENT_FILE_XFER_START] = "file-xfer-start", + | ^~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:109:6: error: array index in initializer not of integer type +../ui/vdagent.c:109:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:110:6: error: ‘VD_AGENT_FILE_XFER_STATUS’ undeclared here (not in a function) + 110 | [VD_AGENT_FILE_XFER_STATUS] = "file-xfer-status", + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:110:6: error: array index in initializer not of integer type +../ui/vdagent.c:110:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:111:6: error: ‘VD_AGENT_FILE_XFER_DATA’ undeclared here (not in a function) + 111 | [VD_AGENT_FILE_XFER_DATA] = "file-xfer-data", + | ^~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:111:6: error: array index in initializer not of integer type +../ui/vdagent.c:111:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:112:6: error: ‘VD_AGENT_CLIENT_DISCONNECTED’ undeclared here (not in a function) + 112 | [VD_AGENT_CLIENT_DISCONNECTED] = "client-disconnected", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:112:6: error: array index in initializer not of integer type +../ui/vdagent.c:112:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:113:6: error: ‘VD_AGENT_MAX_CLIPBOARD’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_CLIPBOARD’? + 113 | [VD_AGENT_MAX_CLIPBOARD] = "max-clipboard", + | ^~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_CLIPBOARD +../ui/vdagent.c:113:6: error: array index in initializer not of integer type +../ui/vdagent.c:113:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:114:6: error: ‘VD_AGENT_AUDIO_VOLUME_SYNC’ undeclared here (not in a function) + 114 | [VD_AGENT_AUDIO_VOLUME_SYNC] = "audio-volume-sync", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:114:6: error: array index in initializer not of integer type +../ui/vdagent.c:114:6: note: (near initialization for ‘msg_name’) +``` + +I come from a Windows world, so I have no idea what is the "libcommon.fa.p" about. +Can someone help here? +Steps to reproduce: +1. Follow the instruction in https://wiki.qemu.org/Hosts/Linux to compile QEMU +Expected result: QEMU would compile correctly +Observed result: Compilation errors. diff --git a/results/classifier/gemma3:12b/device/1087114 b/results/classifier/gemma3:12b/device/1087114 new file mode 100644 index 000000000..cc26b6032 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1087114 @@ -0,0 +1,45 @@ + +assertion "QLIST_EMPTY(&bs->tracked_requests)" failed + +QEMU 1.3.0 on OpenBSD now crashes with an error as shown below and the command line params do not seem to matter. + +assertion "QLIST_EMPTY(&bs->tracked_requests)" failed: file "block.c", line 1220, function "bdrv_drain_all" + +#1 0x0000030d1bce24aa in abort () at /usr/src/lib/libc/stdlib/abort.c:70 + p = (struct atexit *) 0x30d11897000 + mask = 4294967263 + cleanup_called = 1 +#2 0x0000030d1bc5ff44 in __assert2 (file=Variable "file" is not available. +) at /usr/src/lib/libc/gen/assert.c:52 +No locals. +#3 0x0000030b0d383a03 in bdrv_drain_all () at block.c:1220 + bs = (BlockDriverState *) 0x30d13f3b630 + busy = false + __func__ = "bdrv_drain_all" +#4 0x0000030b0d43acfc in bmdma_cmd_writeb (bm=0x30d0f5f56a8, val=8) at hw/ide/pci.c:312 + __func__ = "bmdma_cmd_writeb" +#5 0x0000030b0d43b450 in bmdma_write (opaque=0x30d0f5f56a8, addr=0, val=8, size=1) at hw/ide/piix.c:76 + bm = (BMDMAState *) 0x30d0f5f56a8 +#6 0x0000030b0d5c2ce6 in memory_region_write_accessor (opaque=0x30d0f5f57d0, addr=0, value=0x30d18c288f0, size=1, shift=0, mask=255) + at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:334 + mr = (MemoryRegion *) 0x30d0f5f57d0 + tmp = 8 +#7 0x0000030b0d5c2dc5 in access_with_adjusted_size (addr=0, value=0x30d18c288f0, size=1, access_size_min=1, access_size_max=4, + access=0x30b0d5c2c6b <memory_region_write_accessor>, opaque=0x30d0f5f57d0) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:364 + access_mask = 255 + access_size = 1 + i = 0 +#8 0x0000030b0d5c3222 in memory_region_iorange_write (iorange=0x30d1d5e7400, offset=0, width=1, data=8) + at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:439 + mrio = (MemoryRegionIORange *) 0x30d1d5e7400 + mr = (MemoryRegion *) 0x30d0f5f57d0 + __func__ = "memory_region_iorange_write" +#9 0x0000030b0d5c019a in ioport_writeb_thunk (opaque=0x30d1d5e7400, addr=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:212 + ioport = (IORange *) 0x30d1d5e7400 +#10 0x0000030b0d5bfb65 in ioport_write (index=0, address=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:83 + func = (IOPortWriteFunc *) 0x30b0d5c0148 <ioport_writeb_thunk> + default_func = {0x30b0d5bfbbc <default_ioport_writeb>, 0x30b0d5bfc61 <default_ioport_writew>, 0x30b0d5bfd0c <default_ioport_writel>} +#11 0x0000030b0d5c0704 in cpu_outb (addr=49216, val=8 '\b') at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:289 +No locals. +#12 0x0000030b0d6067dd in helper_outb (port=49216, data=8) at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/target-i386/misc_helper.c:72 +No locals. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1090 b/results/classifier/gemma3:12b/device/1090 new file mode 100644 index 000000000..94d1dae6c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1090 @@ -0,0 +1,16 @@ + +can't create rocker device because setting device array properties on the command line is broken +Description of problem: +it does not accept the prop_array parameter: + +``` +qemu-system-x86_64 -enable-kvm -m 1g -cpu host -netdev socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0 +qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found +``` +Steps to reproduce: +1. just run the command +Additional information: +the latest qemu i find working is 6.1.1... if you start a fedora vm and `dnf install kernel-modules-internal` then the rocker ports appear and work properly... + +thanks, +cs diff --git a/results/classifier/gemma3:12b/device/1090558 b/results/classifier/gemma3:12b/device/1090558 new file mode 100644 index 000000000..24c36816d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1090558 @@ -0,0 +1,10 @@ + +hw/mc146818: error reading RTC_HOURS_ALARM + +get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly. + +- Bit 7 must be masked before conversion from BCD. +- Care must be taken to check the don't care condition before masking. +- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done in convert_hour()). + +Seen in commit e376a788ae130454ad5e797f60cb70d0308babb6. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1090602 b/results/classifier/gemma3:12b/device/1090602 new file mode 100644 index 000000000..ada18d388 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1090604 b/results/classifier/gemma3:12b/device/1090604 new file mode 100644 index 000000000..a92ab6da8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1094786 b/results/classifier/gemma3:12b/device/1094786 new file mode 100644 index 000000000..6a74bfbbd --- /dev/null +++ b/results/classifier/gemma3:12b/device/1094786 @@ -0,0 +1,42 @@ + +static build with curses fails if requires -ltinfo + +On my system (amd64 Debian wheezy/sid) static ncurses build requires -ltinfo: +$ pkg-config --libs --static ncurses +-lncurses -ltinfo + +$ ../../configure --enable-curses --static +# Actually this fails on line + if compile_prog "" "$curses_lib" ; then +# with +ERROR +ERROR: User requested feature curses +ERROR: configure was not able to find it +ERROR +# but if we add -ltinfo to this line check succeds +... +static build yes +... + +$ make +... +... + CC i386-softmmu/hw/i386/../kvm/pci-assign.o + LINK i386-softmmu/qemu-system-i386 +../os-posix.o: In function `change_process_uid': +/home/vadim/soft/qemu/os-posix.c:205: warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking # and many alike warnings +... +../ui/curses.o: In function `curses_cursor_position': +/home/vadim/soft/qemu/ui/curses.c:137: undefined reference to `COLS' +/home/vadim/soft/qemu/ui/curses.c:137: undefined reference to `LINES' +/home/vadim/soft/qemu/ui/curses.c:138: undefined reference to `stdscr' +/home/vadim/soft/qemu/ui/curses.c:139: undefined reference to `curs_set' +../ui/curses.o: In function `curses_calc_pad': +/home/vadim/soft/qemu/ui/curses.c:68: undefined reference to `stdscr' +/home/vadim/soft/qemu/ui/curses.c:69: undefined reference to `stdscr' +... and so on + +I tried to build the very minimal static qemu executable. Actual configure line I tried first was +../../configure --target-list=i386-softmmu --disable-sdl --disable-virtfs --disable-vnc --disable-xen --disable-brlapi --disable-bluez --disable-slirp --disable-kvm --disable-user --disable-vde --disable-vhost-net --disable-spice --disable-libiscsi --disable-smartcard --disable-usb-redir --disable-guest-agent --audio-drv-list= --audio-card-list= --enable-curses --static + +and the errors was the same. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1094950 b/results/classifier/gemma3:12b/device/1094950 new file mode 100644 index 000000000..9686de910 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1094950 @@ -0,0 +1,49 @@ + +crash at qemu_iohandler_poll (iohandler.c:124) on macos 10.8.2 + +I'm seeing consistent hangs / crashes on MacOS 10.8.2 with 1.3.0. I've tried both gcc-4.2 and clang. I've tried a half a dozen different images/kernels. + +I configured qemu like this: + +./configure --disable-sdl --disable-kvm --enable-cocoa --cc=gcc-4.2 --host-cc=gcc-4.2 --enable-debug --extra-cflags=-g --extra-ldflags=-g + +And ran it like this: + +qemu-system-arm -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0" + +With images, kernel, and initrd described here: + +http://psellos.com/2012/08/2012.08.qemu-arm-osx.html + +And I get: + +Program received signal EXC_BAD_ACCESS, Could not access memory. +Reason: KERN_PROTECTION_FAILURE at address: 0x000000010142f2d0 +0x000000010142f2d0 in ?? () + +(gdb) bt +#0 0x000000010142f2d0 in ?? () +#1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 +#2 0x0000000100172acf in main_loop_wait (nonblocking=0) at main-loop.c:418 +#3 0x0000000100207bbf in main_loop () at vl.c:1765 +#4 0x000000010020e7b0 in qemu_main (argc=12, argv=0x7fff5fbff360, envp=0x7fff5fbff3c8) at vl.c:3992 +#5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbff360) at ui/cocoa.m:884 +(gdb) frame 1 +#1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 +124 ioh->fd_read(ioh->opaque); +Current language: auto; currently c +(gdb) p ioh +$1 = (IOHandlerRecord *) 0x10142f110 +(gdb) p *ioh +$2 = { + fd_read_poll = 0, + fd_read = 0x10017212b <sigfd_handler>, + fd_write = 0, + opaque = 0x3, + next = { + le_next = 0x0, + le_prev = 0x105d00bc0 + }, + fd = 3, + deleted = false +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1096714 b/results/classifier/gemma3:12b/device/1096714 new file mode 100644 index 000000000..18650b126 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1096714 @@ -0,0 +1,11 @@ + +qemu 1.3.0: usb devices shouldn't have same vendor/product ID and same serial + +Boot Windows XP with +./qemu-system-i386 -device pci-ohci -device usb-tablet +and then with +./qemu-system-i386 -device pci-ohci -device usb-kbd + +and you will notice, that the usb keyboard is not detected. In fact, Windows XP detects the usb tablet and loads the driver for the tablet instead of the driver for the keyboard. + +The problem seems to be, that vendor and product ID and even the seriel of both the usb tablet and the usb keyboard are the same as an lsusb reveiles. Hence, Windows XP doesn't detect when you replace the tablet by a keyboard and vice versa. I didn't check other USB devices, but it seems a bad idea to me to have devices with the same vendor/product Id. I'm not aware, whether it is sufficient to change the seriel numbers of the devices. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1106 b/results/classifier/gemma3:12b/device/1106 new file mode 100644 index 000000000..f23359182 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1106 @@ -0,0 +1,10 @@ + +undefined address access cause failure +Description of problem: +Hi, +I used serial device as below: +qemu/hw/char/serial.c +It defines only support 8 registers address space(offset 0x00-0x32). And in guest os, the hardware is synopsys dw_apb_uart which is compatible with 16550. +when it access low 8 registers, it works ok. but it may access high address(0x8c) which serial.c not defined, then fail occur. + +Is there anyway to handle this, access address which device not defined, expect it no handle, but not cause system crash. like read is zero and write ignore. diff --git a/results/classifier/gemma3:12b/device/1108 b/results/classifier/gemma3:12b/device/1108 new file mode 100644 index 000000000..540c488ac --- /dev/null +++ b/results/classifier/gemma3:12b/device/1108 @@ -0,0 +1,2 @@ + +D-Bus display does fails to build if libgdm is not detected diff --git a/results/classifier/gemma3:12b/device/1112 b/results/classifier/gemma3:12b/device/1112 new file mode 100644 index 000000000..4247c522a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1112 @@ -0,0 +1,2 @@ + +Heap-overflow in scsi_disk_emulate_write_same diff --git a/results/classifier/gemma3:12b/device/1118 b/results/classifier/gemma3:12b/device/1118 new file mode 100644 index 000000000..737c7ed54 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1118 @@ -0,0 +1,76 @@ + +[AVR] Interrupt skips to incorrect handler when raised after skipping instruction +Description of problem: +If interrupt is raised after instruction that can skip following instruction (for example `CPSE`), and skip condition is active, instead of correct vector, one after it is executed. + +This can happen only if CPSE instruction is at the end of translation block. Usually it is somewhere inside block and very rare arrangement of code is required to get into that error. +Steps to reproduce: +Real world scenario is waiting in busy loop for `std::atomic<bool>` set by interrupt, in bigger application, with optimized code and rare chance of code arrangement. Effect usually is landing in `__bad_interrupt` and reset, but can also be executing other interrupt handler. + +Synthetic example is: + +1. There must be instruction that can skip following instruction (for example `CPSE`), with always-active condition for skip +2. It must be placed in way, that it will be at the end of translation block. + + Example (addresses matter): +``` + ff8: 81 e0 ldi r24, 0x01 ; 1 + ffa: 88 13 cpse r24, r24 + ffc: 01 c0 rjmp .+2 ; 0x1000 + ffe: 80 e0 ldi r24, 0x00 ; 0 + 1000: 00 00 nop +``` + +3. It should be busy-looped to raise chances of encountering that code +4. Any external interrupt should be generated + - the simplest is UART RX on stdin raised by key presses + +Fully working example attached, with ELF file, annotated C code, ASM dump, and Makefile that allows compiling and running this scenario (but I don't guarantee that self-compiling would always generate this error - it can move code a bit). + +(please adjust paths to GCC and QEMU in Makefile before using) + +[avr-irq-fail.zip](/uploads/b702104098a31754d544d6ae6e60e074/avr-irq-fail.zip) + +Running by command: + + ./qemu-system-avr -machine arduino-uno -nographic -monitor null -serial stdio -bios fail.elf + +And then press any key until error happens. + +It is largely machine independent, I originally encountered that on custom Atmega644 machine. +Additional information: +Annotated execution log output of `in_asm`, real-world example: + +``` +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00000ff4: MOVW r31:r30, r25:r24 +0x00000ff6: LDDZ r25, Z+0 +0x00000ff8: LDI r24, 1 +0x00000ffa: CPSE r25, r1 // <-------------------- it must looks like that, with CPSE at the end + +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00000ffc: RJMP .+2 + +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00001000: RET +... +``` +and then: +``` +// <-------------------- INT 20 raised +... +---------------- +IN: +0x00000050: JMP 0x1002 // <-- correct vector loaded... + +---------------- +IN: +0x00000054: JMP 0x1012 // <-- ...but skipping to one after that... + +---------------- +IN: __vector_21 // <-- ...and executing incorrect handler +... +``` diff --git a/results/classifier/gemma3:12b/device/112 b/results/classifier/gemma3:12b/device/112 new file mode 100644 index 000000000..fc225b7a6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/112 @@ -0,0 +1,2 @@ + +setting unsupported timeout for i6300esb watchdog causes hw reset diff --git a/results/classifier/gemma3:12b/device/1128935 b/results/classifier/gemma3:12b/device/1128935 new file mode 100644 index 000000000..1719565f8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1128935 @@ -0,0 +1,24 @@ + +MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction + +I occasionally see that the TLBP instruction fails to find the corresponding TLB entry in the TLB Modified exception handler. This behavior is unexpected, because the invocation of the TLB Modified exception suggests there indeed is such an entry in the TLB and only requires its dirty bit to be set. + +The operating system which can trigger and is susceptible to this behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta. The QEMU version on which this is reproducible is QEMU 1.4.0 and also some others. + +When I looked into the QEMU sources, I noticed the following discrepancy, which could potentially explain the behavior: + + 65 /* MIPS32/MIPS64 R4000-style MMU emulation */ + 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot, + 67 target_ulong address, int rw, int access_type) + 68 { + <snip> + 72 for (i = 0; i < env->tlb->tlb_in_use; i++) { + +1865 void r4k_helper_tlbp(CPUMIPSState *env) +1866 { + <snip> +1875 for (i = 0; i < env->tlb->nb_tlb; i++) { + +From the above it appears as if the the code which searches the TLB for a matching entry searched also the QEMU-specific "shadow" TLB entries, which is, however, not in line with how the TLBP instruction searches the TLB. So if a matching entry is found on index >= tlb_in_use, the HelenOS exception handler using TLBP to locate the entry would hit an assertion on seeing the Index register bit P set. + +I also suspect there is a similar issue with the TLB Invalid exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is not susceptible in this case. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1134 b/results/classifier/gemma3:12b/device/1134 new file mode 100644 index 000000000..ec3e9136a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1134 @@ -0,0 +1,4 @@ + +Make ivshmem more generic not only a PCI device +Additional information: +It will also benefit from making it more portable, see https://gitlab.com/qemu-project/qemu/-/issues/666 diff --git a/results/classifier/gemma3:12b/device/114 b/results/classifier/gemma3:12b/device/114 new file mode 100644 index 000000000..9ccdbd1bb --- /dev/null +++ b/results/classifier/gemma3:12b/device/114 @@ -0,0 +1,2 @@ + +the help message of the set_password subcommand of the qemu monitor isn't usable diff --git a/results/classifier/gemma3:12b/device/1141 b/results/classifier/gemma3:12b/device/1141 new file mode 100644 index 000000000..31da1f015 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1141 @@ -0,0 +1,11 @@ + +virtio-gpu-gl-pci not working with arm/aarch64 +Description of problem: +Since migration to using virtio-gpu-gl-pci instead of virtio-gpu-pci (commit 17cdac0b51bc4ad7a68c3e5e0b1718729b74d512, used git-bisect to find the problem) my arm guests fail to load. If I use -device virtio-gpu-gl-pci, I don't get any image on the virtual guest screen. If I use -device virtio-gpu-pci, I can boot the guest and get the image, but GL acceleration is not working. Changing sdl to gtk doesn't help. +Steps to reproduce: +1. Download debian netinstall boot iso for arm (https://cdimage.debian.org/debian-cd/current/armhf/iso-cd/debian-11.4.0-armhf-netinst.iso) +2. Copy edk2-arm-code.fd and edk2-arm-vars.fd files from build dir. +3. Run command line ```qemu-system-arm -machine virt -m 512 -cdrom debian.iso -device virtio-gpu-gl-pci -display sdl,gl=on,show-cursor=on -pflash edk2-arm-code.fd -pflash edk2-arm-vars.fd```, get a black virtual screen. +4. Run command line ```qemu-system-arm -machine virt -m 512 -cdrom debian.iso -device virtio-gpu-pci -display sdl,gl=on,show-cursor=on -pflash edk2-arm-code.fd -pflash edk2-arm-vars.fd```, get an image on the virtual screen. +Additional information: +I have an x86_64 guest which uses virgl, and it runs fine after 17cdac0b51bc4ad7a68c3e5e0b1718729b74d512 with only changing virtio-gpu-pci to virtio-gpu-gl-pci diff --git a/results/classifier/gemma3:12b/device/1146 b/results/classifier/gemma3:12b/device/1146 new file mode 100644 index 000000000..68d6bd47e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1146 @@ -0,0 +1,102 @@ + +ppc: mac99 immediate segfault in vga_init with bus=pci.0 +Description of problem: +I'm trying to figure out why `mac99` PowerPC VMs launched by libvirt always immediately segfault (signal SIGSEGV, segmentation fault). I narrowed it down to the `bus=pci.0` option that libvirt adds to the `-device VGA` argument. If I remove the `bus=pci.0` option then it doesn't segfault. Full backtrace from gdb: + +``` +#0 memory_region_update_container_subregions (subregion=0x555556d795e0) at ../softmmu/memory.c:2538 + mr = <optimized out> + other = <optimized out> + alias = <optimized out> + __PRETTY_FUNCTION__ = "memory_region_add_subregion_common" +#1 memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555556d795e0) at ../softmmu/memory.c:2556 + alias = <optimized out> + __PRETTY_FUNCTION__ = "memory_region_add_subregion_common" +#2 0x0000555555b81fad in vga_init (s=s@entry=0x555556dbe590, obj=obj@entry=0x555556dbdb70, address_space=0x5555568ea570, address_space_io=address_space_io@entry=0x5555568ea790, init_vga_ports=init_vga_ports@entry=true) at ../hw/display/vga.c:2305 + vga_io_memory = 0x555556d795e0 + vga_ports = 0x55555623bda0 <vga_portio_list> + vbe_ports = 0x55555623bd20 <vbe_portio_list> +#3 0x00005555558fbe3a in pci_std_vga_realize (dev=0x555556dbdb70, errp=<optimized out>) at ../hw/display/vga-pci.c:245 + d = 0x555556dbdb70 + s = 0x555556dbe590 + qext = false + edid = false +#4 0x0000555555990128 in pci_qdev_realize (qdev=0x555556dbdb70, errp=<optimized out>) at ../hw/pci/pci.c:2218 + pci_dev = 0x555556dbdb70 + pc = <optimized out> + klass = <optimized out> + local_err = 0x0 + is_default_rom = <optimized out> + class_id = <optimized out> + __func__ = "pci_qdev_realize" +#5 0x0000555555c6aa2f in device_set_realized (obj=<optimized out>, value=true, errp=0x7fffffffd570) at ../hw/core/qdev.c:553 + dev = 0x555556dbdb70 + dc = 0x555556634130 + hotplug_ctrl = 0x0 + bus = <optimized out> + ncl = <optimized out> + local_err = 0x0 + unattached_parent = false + unattached_count = 12 + __func__ = "device_set_realized" + __PRETTY_FUNCTION__ = "device_set_realized" +#6 0x0000555555c6de7a in property_set_bool (obj=0x555556dbdb70, v=<optimized out>, name=<optimized out>, opaque=0x5555564c40b0, errp=0x7fffffffd570) at ../qom/object.c:2273 + prop = 0x5555564c40b0 + value = true +#7 0x0000555555c70158 in object_property_set (obj=obj@entry=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", v=v@entry=0x555556d745d0, errp=errp@entry=0x7fffffffd570) at ../qom/object.c:1408 + _auto_errp_prop = {local_err = 0x0, errp = 0x7fffffffd570} + prop = <optimized out> + __func__ = "object_property_set" +#8 0x0000555555c73384 in object_property_set_qobject (obj=obj@entry=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", value=value@entry=0x555556d732c0, errp=errp@entry=0x7fffffffd570) at ../qom/qom-qobject.c:28 + v = 0x555556d745d0 + ok = <optimized out> +#9 0x0000555555c703c9 in object_property_set_bool (obj=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", value=value@entry=true, errp=errp@entry=0x7fffffffd570) at ../qom/object.c:1477 + qbool = 0x555556d732c0 + ok = <optimized out> +#10 0x0000555555c69ec2 in qdev_realize (dev=<optimized out>, bus=bus@entry=0x5555568eb750, errp=errp@entry=0x7fffffffd570) at ../hw/core/qdev.c:333 + __PRETTY_FUNCTION__ = "qdev_realize" +#11 0x0000555555a1db80 in qdev_device_add_from_qdict (opts=opts@entry=0x555556d72130, from_json=from_json@entry=false, errp=<optimized out>, errp@entry=0x5555563be3d0 <error_fatal>) at /home/rhansen/floss/qemu/include/hw/qdev-core.h:17 + _auto_errp_prop = {local_err = 0x0, errp = 0x5555563be3d0 <error_fatal>} + dc = 0x555556634130 + driver = 0x555556d73150 "VGA" + path = <optimized out> + id = <optimized out> + dev = 0x555556dbdb70 + bus = <optimized out> + __func__ = "qdev_device_add_from_qdict" +#12 0x0000555555a1dca6 in qdev_device_add (opts=0x5555564c10d0, errp=errp@entry=0x5555563be3d0 <error_fatal>) at ../softmmu/qdev-monitor.c:733 + qdict = 0x555556d72130 + ret = <optimized out> +#13 0x0000555555a1fb83 in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:1142 + dev = <optimized out> +#14 0x0000555555dde692 in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x555555a1fb70 <device_init_func>, opaque=opaque@entry=0x0, errp=0x5555563be3d0 <error_fatal>) at ../util/qemu-option.c:1135 + loc = {kind = LOC_CMDLINE, num = 2, ptr = 0x7fffffffd990, prev = 0x5555563be400 <std_loc>} + opts = 0x5555564c10d0 + next = 0x0 + rc = 0 + __PRETTY_FUNCTION__ = "qemu_opts_foreach" +#15 0x0000555555a22921 in qemu_create_cli_devices () at ../softmmu/vl.c:2522 + opt = <optimized out> + __func__ = "qmp_x_exit_preconfig" + __func__ = "qmp_x_exit_preconfig" +#16 qmp_x_exit_preconfig (errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:2590 + __func__ = "qmp_x_exit_preconfig" + __func__ = "qmp_x_exit_preconfig" +#17 qmp_x_exit_preconfig (errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:2582 + __func__ = "qmp_x_exit_preconfig" +#18 0x0000555555a25ec2 in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:3586 + opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 11 + optarg = 0x7fffffffdec3 "chardev=mon0,mode=readline" + machine_class = <optimized out> + userconfig = <optimized out> + vmstate_dump_file = <optimized out> + __func__ = "qemu_init" + __PRETTY_FUNCTION__ = "qemu_init" +#19 0x000055555585410d in qemu_main (envp=0x0, argv=<optimized out>, argc=<optimized out>) at ../softmmu/main.c:47 + status = <optimized out> +#20 main (argc=<optimized out>, argv=<optimized out>) at ../softmmu/main.c:47 +``` diff --git a/results/classifier/gemma3:12b/device/1149 b/results/classifier/gemma3:12b/device/1149 new file mode 100644 index 000000000..3d36243d4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1149 @@ -0,0 +1,10 @@ + +Micron Xccela (MT35x) NOR Flash wrong implementation in `hw/block/m25p80.c` +Additional information: +I see that in the fork they introduced a new entry - `MAN_MICRON_OCTAL`: - https://github.com/Xilinx/qemu/blob/master/hw/block/m25p80.c + +Would be nice to make it more generic, probably to call just `MAN_MICRON` and set octal mode like quad mode in other flash implementations - via the configuration register flags, especially since they could be enabled and disabled on the fly. + +Also the 256 configuration registers: https://github.com/Xilinx/qemu/commit/9b2fe1e36bfd8849bb3538161279cdff6efea325 + +cc @alistair23 diff --git a/results/classifier/gemma3:12b/device/1155677 b/results/classifier/gemma3:12b/device/1155677 new file mode 100644 index 000000000..765e00060 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/116 b/results/classifier/gemma3:12b/device/116 new file mode 100644 index 000000000..78dda4b99 --- /dev/null +++ b/results/classifier/gemma3:12b/device/116 @@ -0,0 +1,2 @@ + +qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974 diff --git a/results/classifier/gemma3:12b/device/1161 b/results/classifier/gemma3:12b/device/1161 new file mode 100644 index 000000000..cde2c7f2b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1161 @@ -0,0 +1,2 @@ + +revise docs/interop/virtio-balloon-stats.rst diff --git a/results/classifier/gemma3:12b/device/1164 b/results/classifier/gemma3:12b/device/1164 new file mode 100644 index 000000000..4f7b5d913 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1164 @@ -0,0 +1,18 @@ + +q35: incorrect values for PCIEXBAR masks +Description of problem: +https://lore.kernel.org/all/1fded151ce5ecbf7010427871b908000b2aba9ee.1520867956.git.x1917x@gmail.com/ + +In function [mch_update_pciexbar](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/q35.c#L295) + +There are two small issues in PCIEXBAR address mask handling: +- wrong bit positions for address mask bits (see PCIEXBAR description + in Q35 datasheet) +- incorrect usage of 64ADR_MASK + +Due to this, attempting to write a valid PCIEXBAR address may cause it to +shift to another address, causing memory layout corruption where emulated +MMIO regions may overlap real (passed through) MMIO ranges. Fix this +by providing correct values. +Additional information: +Q35 datasheet: https://www.intel.com/Assets/PDF/datasheet/316966.pdf ( 5.1.16 PCIEXBAR—PCI Express* Register Range Base Address ) diff --git a/results/classifier/gemma3:12b/device/1171 b/results/classifier/gemma3:12b/device/1171 new file mode 100644 index 000000000..e01c8a07d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1171 @@ -0,0 +1,4 @@ + +tulip: DMA reentrancy issue leads to stack overflow (CVE-2022-2962) +Description of problem: +A DMA reentrancy issue was found in the tulip emulation. When tulip reads or writes to rx/tx descriptor ( tulip_desc_read/write ) or copies rx/tx frame(tulip_copy_rx_bytes / tulip_copy_tx_buffers), it doesn't check whether the destination address is its own MMIO address. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host. diff --git a/results/classifier/gemma3:12b/device/1175513 b/results/classifier/gemma3:12b/device/1175513 new file mode 100644 index 000000000..e8557ccd0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1175513 @@ -0,0 +1,12 @@ + +Qemu 1.5-git gpu clock control doesn`t work after guest reboot + +I run qemu from git with such command: + +qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 -cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on -device vfio-pci,host=02:00.0,x-vga=on \ +-enable-kvm -monitor stdio -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device intel-hda -device hda-duplex \ +-drive file='/home/<user>/qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \ +-drive file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \ +-spice port=5930,disable-ticketing + +Before guest (Windows 7) reboot, videocard works in 3D mode with full frequency. But after reboot videocard works in 3D only with powersafe frequency. Then I must reboot host for recover gpu clock control. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/118 b/results/classifier/gemma3:12b/device/118 new file mode 100644 index 000000000..e50eb4e1c --- /dev/null +++ b/results/classifier/gemma3:12b/device/118 @@ -0,0 +1,2 @@ + +USB device 1.1 not correctly passedthru from Linux host to Windows guest diff --git a/results/classifier/gemma3:12b/device/1180 b/results/classifier/gemma3:12b/device/1180 new file mode 100644 index 000000000..da10f041d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1180 @@ -0,0 +1,167 @@ + +Assertion failure in usb_cancel_packet() +Description of problem: +When I ran hcd-ohci with dev-storage, I found an assertion failure in +usb_cancel_packet() [1] due to p->state == USB_PACKET_COMPLETE. This is due to +the inconsistency when resetting device. + +``` c +static inline bool usb_packet_is_inflight(USBPacket *p) +{ + return (p->state == USB_PACKET_QUEUED || + p->state == USB_PACKET_ASYNC); +} + +void usb_cancel_packet(USBPacket * p) +{ + bool callback = (p->state == USB_PACKET_ASYNC); + assert(usb_packet_is_inflight(p)); // <------------------------------- [1] + usb_packet_set_state(p, USB_PACKET_CANCELED); + QTAILQ_REMOVE(&p->ep->queue, p, queue); + if (callback) { + usb_device_cancel_packet(p->ep->dev, p); + } +} +``` +Steps to reproduce: +Step 1: download the prepared rootfs and the image. + +https://drive.google.com/file/d/1B95zWWcomvZt1wms31Ddc9Xwlq-bfqhq/view?usp=sharing + +https://drive.google.com/file/d/1pxFzn49MKYmMMIIsaL9aUkzebRSYfq3J/view?usp=sharing + +Step 2: run the following script. + +``` bash +QEMU_PATH=../../../qemu/build/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -usb \ + -device pci-ohci,num-ports=6 \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ + -device usb-storage,port=1,drive=disk0 \ + -nographic +``` + +Step 3: with spawned shell (the user is root and the password is empty), run +`ohci-03`. +Additional information: +1 With crafted ED and TD, we can have the ohci->usb_packet's status to be +USB_RET_ASYNC [5]. And thus ohci->async_td is not NULL anymore [2]. + +``` +ed0 = { flags = 0x685f0900, tail = 0x0, head = &td0, next = 0 } + +td0 = { flags = 0x0, cbp = 0x1b8ffc, next = 0, be = 0x1b901a } +# data from cbp to be +55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 03 USBC............ +e8 56 20 40 e8 56 20 40 e8 56 20 40 e8 56 20 + +ed1 = { flags = 0x08303080, tail = 0x0, head = &td1, next = 0 } + +td1 = { flags = 0x90000000, cbp = 0x19affc, next = 0, be = 0x19b01a } +# data from cbp to be +55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 03 USBC............ +e8 56 20 40 e8 56 20 40 e8 56 20 40 e8 56 20 +``` + +``` c +static int ohci_service_td(OHCIState *ohci, struct ohci_ed *ed) +{ + // ... + usb_handle_packet(dev, &ohci->usb_packet); // <------------------- [4] + if (ohci->usb_packet.status == USB_RET_ASYNC) { + usb_device_flush_ep_queue(dev, ep); + ohci->async_td = addr; // <----------------------------------- [2] + return 1; + } +``` + +At the same time, the dev-storage will ref the current usb_packet +(ohci->usb_packet) [4][3]. + +``` +static void usb_msd_handle_data(USBDevice *dev, USBPacket *p) { + // ... + s->packet = p; // <----------------------------------------------- [3] + p->status = USB_RET_ASYNC; // <----------------------------------- [5] + // ... +} +``` + +2 We can first issue `MMIO_WRITE, 0xe0000054, 0x4, 0x4e33b4bf` to reset +the dev-storage device. This will mark the state of ohci->usb_packet to +USB_PACKET_COMPLETE and clear s->packet. + +``` +ohci_mem_write + ohci_port_set_status + usb_device_reset + usb_device_handle_reset + usb_msd_handle_reset + usb_msd_packet_complete + usb_packet_complete +``` + +3 We can then issue `MMIO_WRITE, 0xe0000004, 0x4, 0x3d8d323a` to reset the +roothub and this will invoke ohci_stop_endpoints() where usb_cancel_packet() +is invoked and thus [1] fails as the state of ohci->usb_packet has been changed +to USB_PACKET_COMPLETE. + +``` +ohci_set_ctl + ohci_roothub_reset + ohci_stop_endpoints + if (ohci->async_td != NULL) usb_cancel_packet(&ohci->usb_packet); + assert(usb_packet_is_inflight(p)); // boom +``` + +The above callstack are simplified. The complete callstack is in the following. + +``` +ohci_set_ctl + ohci_roothub_reset + usb_port_reset + usb_detach + ohci_detach + ohci_child_detach // <-------------------------------- [8] + usb_device_reset // <----------------------------------------- [6] + usb_device_handle_reset + usb_msd_handle_reset + usb_msd_packet_complete + usb_packet_complete + ohci_stop_endpoints // <------------------------------------------ [7] + if (ohci->async_td != NULL) usb_cancel_packet(&ohci->usb_packet); + assert(usb_packet_is_inflight(p)); // boom +``` + +Interestingly, in ohci_roothub_reset(), usb_device_reset() is also invoked [6] +just like what in step 2. I adjusted my PoC by removing step 2. However, I +cannot reproduce this assertion failure. Therefore, there is something different +bewteen [6] and step 2. + +Then, I found at [8], ohci_child_detach() cancels the ohci->usb_packet and reset +ohci->async_td. With step 2, as the status of the ohci->usb_packet has changed +to USB_PACKET_COMPLETE, usb_cancel_packet() will not be invoked. Without step 2, +as the status of the ohci->usb_packet is still USB_PACKET_ASYNC, +usb_cancel_packet() will be invoked and thus everything goes fine. + +``` +static void ohci_child_detach(USBPort *port1, USBDevice *dev) +{ + OHCIState *ohci = port1->opaque; + + if (ohci->async_td && + usb_packet_is_inflight(&ohci->usb_packet) && + ohci->usb_packet.ep->dev == dev) { + usb_cancel_packet(&ohci->usb_packet); + ohci->async_td = 0; + } +} +``` diff --git a/results/classifier/gemma3:12b/device/1180924 b/results/classifier/gemma3:12b/device/1180924 new file mode 100644 index 000000000..66f94b7de --- /dev/null +++ b/results/classifier/gemma3:12b/device/1180924 @@ -0,0 +1,19 @@ + +fails to handle a usb serial port with a specific vendorid + +If I run qemu-system-i386 with arguments +-usb -usbdevice serial:vendorid=1221:pty +(this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here: +http://qemu.weilnetz.de/qemu-doc.html +), it says +char device redirected to /dev/pts/<something> (label usbserial0) +qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found +Aborted +and exits. Moreover, if I try to add such a device to a running machine by typing usb_add serial:vendorid=1221:pty in the machine's control terminal (to reach it, I press ctrl-alt-2), qemu also writes +char device redirected to /dev/pts/<something> (label usbserial0) +Aborted +to the terminal where I run it from and exits. To the quest OS this looks like a power failure which causes all the programs inside the virtual machine to lose their unsaved data. +I have tested this with qemu-1.5.0-rc2, actually, the issue occured in a similar way since 1.0.1, but did not occur in 0.11.1. +The issue is reproducible always, even if I don't specify any hard disk in the command line, i. e. +$ qemu-system-i386 -usb -usbdevice serial:vendorid=1221:pty +, so I believe it is guest OS -independent. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1181 b/results/classifier/gemma3:12b/device/1181 new file mode 100644 index 000000000..357f21ca2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1181 @@ -0,0 +1,2 @@ + +Question for AVR experts... diff --git a/results/classifier/gemma3:12b/device/1181354 b/results/classifier/gemma3:12b/device/1181354 new file mode 100644 index 000000000..d3f63d90f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1181354 @@ -0,0 +1,4 @@ + +assert failed in scsi-bus.c line 1539 in SCSI_XFER_NONE + +Every time I format a SCSI hard disk (on ID 0) with Windows NT or DOS, QEMU crashes with an assertion failure on scsi-bus.c, any help? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1185888 b/results/classifier/gemma3:12b/device/1185888 new file mode 100644 index 000000000..30ada1ea8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1185888 @@ -0,0 +1,26 @@ + +-device nec-usb-xhci (usb 3) breaks VM snapshots + +Enabling the USB 3.0 controller apparently breaks "live" snapshotting. + +To reproduce: + + $ qemu-system-x86_64 -device nec-usb-xhci vm.qcow2 + +then, at the Monitor: + + (qemu) savevm + Error -22 while writing VM + (qemu) + +Instead, if I remove -device nec-usb-xhci from the cmdline, everything works fine. + +Some QEMU and OS info: + + $ qemu-system-x86_64 -version + QEMU emulator version 1.5.0, Copyright (c) 2003-2008 Fabrice Bellard + + $ uname -a + Linux localhost 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux + +The same also happens with 1.4.2. All compiled from source, not Debiabn package (btw, this *also* happens with distro packages/older versions). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1187529 b/results/classifier/gemma3:12b/device/1187529 new file mode 100644 index 000000000..065f91fbf --- /dev/null +++ b/results/classifier/gemma3:12b/device/1187529 @@ -0,0 +1,12 @@ + +Devices on PCI bridge stop working when live-migrated + +qemu version: 1.4.50 (0ca5aa4f4c4a8bcc73988dd52a536241d35e5223) +host: x86_64, Linux 3.6.10 (Fedora 17) +client: x86_64 Centos 6.3 (doesn't matter, really) + +If a device, e.g. an lsi53c895a, is on a pci-bridge, after migration, the device stops working (e.g., commands like "poweroff" +get an Input/Output error. Fails under either xen or kvm. If "top" was running, some cpus go to ~100% wait. + +Sample KVM invocation line: +qemu-system-x86_64 -machine type=pc,accel=kvm -m 4096 -device pci-bridgemsi=on,chassis_nr=1,id=pciBridge1.0,addr=0x11.0 -device lsi53c895a,id=sas,bus=pciBridge1.0,addr=0x1.0x0 -drive if=none,id=disk0,file=/path/to/disk/image -device scsi-disk,bus=sas.0,scsi-id=0,drive=disk0 -vnc 127.0.0.1:0,to=99 -serial pty -boot order=cda -smp 4,maxcpus=4 -monitor vc \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/119 b/results/classifier/gemma3:12b/device/119 new file mode 100644 index 000000000..fea0d9512 --- /dev/null +++ b/results/classifier/gemma3:12b/device/119 @@ -0,0 +1,2 @@ + +USB assert failure on hcd-uhci.c diff --git a/results/classifier/gemma3:12b/device/1190525 b/results/classifier/gemma3:12b/device/1190525 new file mode 100644 index 000000000..c557976a6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1196 b/results/classifier/gemma3:12b/device/1196 new file mode 100644 index 000000000..2e6ca5270 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1196 @@ -0,0 +1,13 @@ + +Guest could not enable pci AtomicOp requests for passthrough device +Description of problem: +Guest could not enable pci AtomicOp requests for passthrough device. + +sudo setpci -v -d *:706t 8c.b=40 // enable pci AtomicOp requests bit in the guest os. + +Host could not see the bit by command "sudo lspci -vvv -s 03:00.0". +Steps to reproduce: +1. sudo setpci -v -d *:706t 8c.b=40 // in the guest os +2. sudo lspci -vvv -s 03:00.0 // in the host os +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1196145 b/results/classifier/gemma3:12b/device/1196145 new file mode 100644 index 000000000..45db9129d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1196145 @@ -0,0 +1,19 @@ + +usb-host: hostaddr=0XX is parsed as octal number + +when doing + +device_add usb-host,hostaddr=010 + +taking 010 in the format of both lsusb or udev, qemu parses an octal number and assumes hostaddr=8. +(i used a 2.0 device on the ehci.0 bus) +at least to me that is confusing. + +also: + +when adding a non-existent usb device (bogus hostaddr), the following is created according to 'usb info': + + Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device + +in usb_qdev_init(): +usb_claim_port is called but usb_device_init does not report an error and thus usb_release_port is not called. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1198350 b/results/classifier/gemma3:12b/device/1198350 new file mode 100644 index 000000000..3a0bbd632 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1198350 @@ -0,0 +1,46 @@ + +USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument + +Host Gentoo linux 32bit +Guest Windows XP SP3 +qemu 1.4.2 and +qemu fresh get clone and build 2013-07-04 (version1.5.50) +qemu command line + +qemu-system-i386 -enable-kvm localtime -m 2047 -boot d /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb -device usb-ehci,id=ehci -usbdevice host:1493:19 + +The device I am trying to use with the guest is an interface for the Suunto Ambit 2 GPS watch which has no linux support. + +When the USB device is plugged in qemu reports to the command line: + +USBDEVFS_DISCONNECT: Invalid argument +Invalid argument + +dmesg shows + +[237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci +[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 +[237755.582781] usb 2-1.5: config 1 has no interface number 0 +[237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019 +[237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[237755.583633] usb 2-1.5: Product: Ambit +[237755.583634] usb 2-1.5: Manufacturer: Suunto +[237755.583636] usb 2-1.5: SerialNumber: CE83095110000700 +[237756.584937] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci +[237756.832658] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci +[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use + +In the windows guest Device Manager a HID device is listed but nothing else happens, no found new hardware dialog or the Suunto software (which is sitting there waiting) is not triggered as it should be. + +I have tried successfully with several other devices (flash drive, mouse, printer and video capture device). Because this device pretends to be an HID device my kernel's hid-generic driver was picking it up first until I modified hid-core.c to ignore this vendorid/productid. But still no joy. + +I'm guessing it has something to do with the the dmesg lines: + +[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0 +[237755.582781] usb 2-1.5: config 1 has no interface number 0 + +But read that these warnings are not important though I don't get them for other devices. Nor do I get: + +[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use + +I've done alot of searching and I've run out of ideas. Any help would be great. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/120 b/results/classifier/gemma3:12b/device/120 new file mode 100644 index 000000000..96468af9e --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1200212 b/results/classifier/gemma3:12b/device/1200212 new file mode 100644 index 000000000..8393ea51d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1200212 @@ -0,0 +1,15 @@ + +qemu-system-arm aborts in lsi_soft_reset + +Qemu compiled from master branch (fetched on 11th Jul 2013, qemu-system-arm -version prints "QEMU emulator version 1.5.50, Copyright (c) 2003-2008 Fabrice Bellard") running on OSX 10.6.8 crashes during Debian 7.1 netboot installation with error: "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." + +Steps to reproduce: + +1. Get kernel and initrd from http://ftp.debian.org/debian/dists/Debian7.1/main/installer-armel/20130613/images/versatile/netboot/ . +2. Create a hard disk image with qemu-img: qemu-img create -f qcow2 debian.qcow2 2G. +3. Run arm-softmmu/qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4-versatile \ + -initrd initrd-3.2.0-4-versatile-netboot -drive file=debian.qcow2,index=0,if=scsi,media=disk \ + -append "console=ttyAMA0" -nographic -net user,hostfwd=tcp:127.0.0.1:22080-:80,vlan=0 \ + -net nic,vlan=0 -smp 1,cores=4 + +The installation should proceed past partition setup and start downloading packages onto hard disk. After several tries I've never got past 31% with the package downloads before getting Abort trap with "Assertion failed: (QTAILQ_EMPTY(&s->queue)), function lsi_soft_reset, file hw/scsi/lsi53c895a.c, line 351." message. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1205156 b/results/classifier/gemma3:12b/device/1205156 new file mode 100644 index 000000000..d40fddd60 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1205156 @@ -0,0 +1,15 @@ + +Errors while compiling version 1.5.2 + +Environment: Ubuntu 13.04 + +"hw/ide/macio.c: In function ‘pmac_ide_atapi_transfer_cb’: +hw/ide/macio.c:134:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format] +hw/ide/macio.c: In function ‘pmac_ide_transfer_cb’: +hw/ide/macio.c:215:5: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int64_t’ [-Werror=format] +hw/ide/macio.c:222:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format] +hw/ide/macio.c:264:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format] +cc1: all warnings being treated as errors +make: *** [hw/ide/macio.o] Error 1" + +I got the source files with a "git clone git://git.qemu-project.org/qemu.git" + a recent "git fetch" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1208 b/results/classifier/gemma3:12b/device/1208 new file mode 100644 index 000000000..c7a1694fa --- /dev/null +++ b/results/classifier/gemma3:12b/device/1208 @@ -0,0 +1,10 @@ + +Raspberry Pi 4 Model B +Additional information: +There have been some attempts at implementing this a few years ago: see: +* https://gitlab.com/philmd/qemu/-/tree/raspi4_wip +* https://github.com/0xMirasio/qemu-patch-raspberry4 + + + +Thanks! diff --git a/results/classifier/gemma3:12b/device/1211 b/results/classifier/gemma3:12b/device/1211 new file mode 100644 index 000000000..fcfd38f5e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1211 @@ -0,0 +1,8 @@ + +Bad fonts in "cirrus" VGA card. +Description of problem: +Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file. +Steps to reproduce: +Similar to #988. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1219234 b/results/classifier/gemma3:12b/device/1219234 new file mode 100644 index 000000000..0d3e6bd47 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1219234 @@ -0,0 +1,15 @@ + +-device ide-hd will assign bus with with no free units + +Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118 + +./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb +qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units +qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed. +qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized + +If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. + +This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct. + +I know -device is the 'build it yourself' approach so I understand if this is WONTFIX. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1223477 b/results/classifier/gemma3:12b/device/1223477 new file mode 100644 index 000000000..48b1cf6cf --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1226531 b/results/classifier/gemma3:12b/device/1226531 new file mode 100644 index 000000000..bc5e4ed38 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1226531 @@ -0,0 +1,39 @@ + +Incorrect logic in ARMv7M interrupt handler + +On ARMv7M interrupts handlers will be called even if emulated code executes "cpsid i" instruction. + +Underlying cause described below: + +In cpu-exec.c:cpu_exec there is a block of code that determines if an interrupt should be raised or not: + + + /* ARMv7-M interrupt return works by loading a magic value + into the PC. On real hardware the load causes the + return to occur. The qemu implementation performs the + jump normally, then does the exception return when the + CPU tries to execute code at the magic address. + This will cause the magic PC value to be pushed to + the stack if an interrupt occurred at the wrong time. + We avoid this by disabling interrupts when + pc contains a magic address. */ + if (interrupt_request & CPU_INTERRUPT_HARD + && ((IS_M(env) && env->regs[15] < 0xfffffff0) + || !(env->uncached_cpsr & CPSR_I))) { + env->exception_index = EXCP_IRQ; + cc->do_interrupt(cpu); + next_tb = 0; + } + +I'm not convinced the logic is correct. +The logic for ARMv7M should be: + +If an interrupt is pending (interrupt_request & CPU_INTERRUPT_HARD) +AND +Interrupts are not disabled ( !(env->uncached_cpsr & CPSR_I) ) +AND +PC doesn't have a magic value (env->regs[15] < 0xfffffff0) + +The current logic seems fires the interrupt if interrupts are enabled OR the PC isn't magic, which is basically all the time. + +I'm not sure what the cleanest patch for this would be. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1234 b/results/classifier/gemma3:12b/device/1234 new file mode 100644 index 000000000..c7351fcd4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1234 @@ -0,0 +1,4 @@ + +Migration: Device state not saved for msmouse/chardevs +Additional information: +This missing feature was discovered while fixing msmouse here: https://patchew.org/QEMU/20220908173120.16779-1-arwed.meyer@gmx.de/20220908173120.16779-2-arwed.meyer@gmx.de/ diff --git a/results/classifier/gemma3:12b/device/1237625 b/results/classifier/gemma3:12b/device/1237625 new file mode 100644 index 000000000..9ff3d0402 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1237625 @@ -0,0 +1,49 @@ + +Cannot read serial from /sys/bus/usb/devices/ + +After an update to qemu 1.6 I can't start any of my images. Qemu always crashs. I tried it with root and as a normal user... Here are some log entries I get: + +Type: Warning Num: 85 +Date: 2013.10.09 23:48:46 549 +Sender: bool System_Info::Scan_USB_Sys( QList<VM_USB> &list ) +Message: Cannot read serial from /sys/bus/usb/devices/ + +Type: Debug Num: 86 +Date: 2013.10.09 23:48:46 553 +Sender: void Virtual_Machine::QEMU_Started() +Message: QEMU Start + +Type: Debug Num: 87 +Date: 2013.10.09 23:48:46 554 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: Begin + +Type: Debug Num: 88 +Date: 2013.10.09 23:48:46 554 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: End + +Type: Debug Num: 89 +Date: 2013.10.09 23:48:46 575 +Sender: void Virtual_Machine::QEMU_Started() +Message: emit Loading_Complete() + +Type: Debug Num: 90 +Date: 2013.10.09 23:48:47 470 +Sender: void Virtual_Machine::QEMU_Finished( int exitCode, QProcess::ExitStatus exitStatus ) +Message: QEMU Finished + +Type: Debug Num: 91 +Date: 2013.10.09 23:48:47 470 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: Begin + +Type: Debug Num: 92 +Date: 2013.10.09 23:48:47 470 +Sender: bool Virtual_Machine::operator==( const Virtual_Machine &vm ) const +Message: End + +Type: Error Num: 93 +Date: 2013.10.09 23:48:47 498 +Sender: QEMU Crashed! +Message: \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1240669 b/results/classifier/gemma3:12b/device/1240669 new file mode 100644 index 000000000..ba13dd476 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1240669 @@ -0,0 +1,40 @@ + +sd_init() generates SIGSEGV when passed NULL + +Ran into a bug following the following tutorial: +http://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/ + +I built QEMU from a clone of master and became stuck at the beginning part of the tutorial where only u-boot.bin is exectuted. + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4f8a066b5fc254eeaabbbde56ba4f5b29cc68fdf +See the modifications to sd.c specifically. + +When sd_init (sd.c) is called from pl181_init(), bs is potentially null: +s->card = sd_init(dinfo ? dinfo->bdrv : NULL, false); + +sd_init() : +SDState *sd_init(BlockDriverState *bs, bool is_spi) +{ + SDState *sd; + + sd = (SDState *) g_malloc0(sizeof(SDState)); + sd->buf = qemu_blockalign(bs, 512); + sd->spi = is_spi; + sd->enable = true; + sd_reset(sd, bs); + if (sd->bdrv) { + bdrv_attach_dev_nofail(sd->bdrv, sd); + bdrv_set_dev_ops(sd->bdrv, &sd_block_ops, sd); + } + vmstate_register(NULL, -1, &sd_vmstate, sd); + return sd; +} + +Line 497 calls bdrv_is_read_only(bs) (from block.c)and this generates a SEGSIGV. + +int bdrv_is_read_only(BlockDriverState *bs) +{ + return bs->read_only; +} + +Checking out tag v1.6.1 reverted the problem. Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1243 b/results/classifier/gemma3:12b/device/1243 new file mode 100644 index 000000000..4b2710310 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1243 @@ -0,0 +1,2 @@ + +Floating-point-exception in ide_set_sector diff --git a/results/classifier/gemma3:12b/device/1247478 b/results/classifier/gemma3:12b/device/1247478 new file mode 100644 index 000000000..9ef07281d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1248168 b/results/classifier/gemma3:12b/device/1248168 new file mode 100644 index 000000000..4a44f9466 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1248168 @@ -0,0 +1,25 @@ + +MIPS, self-modifying code and uncached memory + +Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region. + +For example, when running this code I get unexpected behavior: + + 0: e3000010 b 0x390 + 4: 00000000 nop + ... + 380: 00701f40 mfc0 ra,c0_epc + 384: 0400e0bb swr zero,4(ra) + 388: 18000042 eret + 38c: 00000000 nop + 390: 25500000 move t2,zero + 394: 02000b34 li t3,0x2 + 398: 23504b01 subu t2,t2,t3 + 39c: e9003c0b j 0xcf003a4 + 3a0: 0a004a21 addi t2,t2,10 + 3a4: ffff0010 b 0x3a4 + 3a8: 00000000 nop + 3ac: 00000000 nop + + I expect that swr instruction in line 384 would change `addi t2,t2,1`0 to `nop` +This should work because no cache is used for this memory region. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1248469 b/results/classifier/gemma3:12b/device/1248469 new file mode 100644 index 000000000..8a37a402d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1248469 @@ -0,0 +1,4 @@ + +qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit + +boot windows 7 32bit guest with -readconfig q35-chipset.cfg paramter,in guest's device manager,there's a device 3420 not work,it shows error "This device cannot find enough free resources that it can use(code 12)". \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1250 b/results/classifier/gemma3:12b/device/1250 new file mode 100644 index 000000000..fe78e6c84 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1250 @@ -0,0 +1,4 @@ + +[RFE] on windows, attach any storport disk directly, not just physicaldrives +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1252270 b/results/classifier/gemma3:12b/device/1252270 new file mode 100644 index 000000000..422e5624b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1252270 @@ -0,0 +1,16 @@ + +installing NT4 on MIPS Magnum/Jazz asserts + +While installing NT4 on MIPS Magnum (Jazz), when the NT Installer tries to format the harddisk, QEmu 1.6.1 crashes with an assertion: + +qemu-system-mips64el: g364: invalid read at [0000000000102000] +qemu-system-mips64el: hw/scsi/scsi-bus.c:1577: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed. +./nt4mips.sh: line 3: 20336 Aborted (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384 + +This assertion also occurred with the stock Ubuntu version of QEmu (1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)) which I tried before. + +Note that to even get this far, you need the patch mentioned in BUG1245924, otherwise QEmu 1.6.1 won't even start/boot at all + +NT4 installation guide I'm following: +http://gunkies.org/wiki/Installing_Windows_NT_4.0_on_Qemu(MIPS) +http://virtuallyfun.superglobalmegacorp.com/?p=2255 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1254 b/results/classifier/gemma3:12b/device/1254 new file mode 100644 index 000000000..0722c8b3a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1254 @@ -0,0 +1,56 @@ + +hw: misc: edu: two off-by-one errors +Description of problem: +In `hw/misc/edu.c`, `edu_check_range()` fails for boundary conditions where `size2 == 0` and `size2 == size1`. +Steps to reproduce: +Two ways to reproduce (attached test program, [foo.c](/uploads/9cbef4f72d175b8336b58f607e262d7b/foo.c)) + +error: +1. `gcc -o foo foo.c` +2. `./foo` + +fix: +1. `gcc -DFIXED -o foo foo.c` +2. `./foo` + +Using `qtest`: (see "QEMU command line" above). +Additional information: +(output of `foo` without fix): +``` +EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000000000-0xffffffffffffffff)! +EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000000000-0x0000000000000fff)! +``` + +Output of `qtest` without the fix: +``` +qemu: hardware error: EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000040000-0x0000000000040fff)! +CPU #0: +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000663 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +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=0000000000000000 0000000000000000 XMM01=0000000000000000 0000000000000000 +XMM02=0000000000000000 0000000000000000 XMM03=0000000000000000 0000000000000000 +XMM04=0000000000000000 0000000000000000 XMM05=0000000000000000 0000000000000000 +XMM06=0000000000000000 0000000000000000 XMM07=0000000000000000 0000000000000000 +``` + +Patch has been submitted to `qemu-devel` diff --git a/results/classifier/gemma3:12b/device/1256122 b/results/classifier/gemma3:12b/device/1256122 new file mode 100644 index 000000000..175f44344 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1256122 @@ -0,0 +1,23 @@ + +vfio bug with all no VGA card + +Hello, + +I whant to report to you a realy big bug. + +vfio passthrough work only with VGA card ! When i try to use vfio with any other PCI or PCI-E card it does not work. + +When i use vfio for VGA i can reboot (or shutdown and start again) my VM with out problem, but for any other PCI card the VM refuse to reboot. + +In dmesg i have this error : + +dmar: DRHD: handling fault status reg 2 +dmar: DMAR:[DMA Read] Request device [xx:xx.x] fault addr 2affde000 +DMAR:[fault reason 06] PTE Read access is not set + +and some time the same but for Write and not Read. + +I found a kind of work around but it's ugly. Just detach your devices from vfio, re-atach to his normal driver and bind again to vfio. + +For information i use an Asrock Z87 Extrem 6 with a CoreI5 4570S +My kernel is 3.12 and Qemu is 1.7-rc0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1266 b/results/classifier/gemma3:12b/device/1266 new file mode 100644 index 000000000..747d82ff0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1266 @@ -0,0 +1,2 @@ + +Assert in resettable_phase_enter through virtio-scsi diff --git a/results/classifier/gemma3:12b/device/1268 b/results/classifier/gemma3:12b/device/1268 new file mode 100644 index 000000000..0a624c810 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1268 @@ -0,0 +1,2 @@ + +erst: undefined-behavior in memcpy in write_erst_record diff --git a/results/classifier/gemma3:12b/device/1268596 b/results/classifier/gemma3:12b/device/1268596 new file mode 100644 index 000000000..651822943 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1268596 @@ -0,0 +1,25 @@ + +Compilation Error: hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function + +Qemu git-cloned from mo. 13.01.14 (ca. 13:00 GMT), Version 1.7.50 + + +#git clone git://git.qemu-project.org/qemu.git +# cd qemu; git submodule update --init dtc +#./configure --disable-xen --enable-kvm +...No Errors... + +#CC="ccache gcc" make -j8 +.... + GEN qemu.1 + Signing optionrom/kvmvapic.bin + GEN qemu-img.1 + CC qapi-types.o +hw/virtio/dataplane/vring.c: In function ‘vring_pop’: +hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function [-Werror=uninitialized] +cc1: all warnings being treated as errors +make: *** [hw/virtio/dataplane/vring.o] Error 1 +make: *** Waiting for unfinished jobs.... + + +Thx. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1269628 b/results/classifier/gemma3:12b/device/1269628 new file mode 100644 index 000000000..e7a6eb85c --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1279257 b/results/classifier/gemma3:12b/device/1279257 new file mode 100644 index 000000000..0b7c8856b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1279257 @@ -0,0 +1,12 @@ + +[hw/scsi/scsi-bus.c:910]: (style) Expression '(X & 0x4) == 0x1' is always false. + +Source code is + + } else if ((buf[1] & 4) == 1) { + +Suggest code rework. I found this bug by running +static analyser cppcheck over the source code. + +I also checked the latest code on the web and the +bug exists there also. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1280521 b/results/classifier/gemma3:12b/device/1280521 new file mode 100644 index 000000000..dac9c108c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1280521 @@ -0,0 +1,4 @@ + +Plan 9 can't use GUI well emulating a RTL8139 card + +The OS Plan 9 from Bell Labs runs fine in QEMU/KVM for the most part buy is unable to boot its GUI when emulating a RTL8139 WiFi card. I hear someone was able to get it working under a Windows XP host but I can't seem to do it under a Gentoo host. If you have any idea what may be doing this I would love to hear it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1282 b/results/classifier/gemma3:12b/device/1282 new file mode 100644 index 000000000..621cc549e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1282 @@ -0,0 +1,4 @@ + +sdhci: DMA reentrancy issue leads to an infinite loop +Description of problem: +When sdhci transfers multiple blocks, it doesnot check if the dma-write buffer pointer overlaps with its MMIO region, crafted content can cause DoS because of infinite loop and CPU consumption. diff --git a/results/classifier/gemma3:12b/device/1284 b/results/classifier/gemma3:12b/device/1284 new file mode 100644 index 000000000..054788250 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1284 @@ -0,0 +1,15 @@ + +macOS QXL VGA not available +Description of problem: +``` +qemu-system-aarch64: QXL VGA not available +``` +``` +qemu-system-aarch64: -device qxl-vga: 'qxl-vga' is not a valid device model name +``` +Steps to reproduce: +1. Build QEMU on macOS with SPICE support (meson) +2. Run commands listed above +3. Observe QXL not working +Additional information: +I'm wiring up QEMU SPICE support on Darwin for Nixpkgs. The same issue can be observed in macports qemu builds with spice. Could this be a packaging issue? diff --git a/results/classifier/gemma3:12b/device/1284090 b/results/classifier/gemma3:12b/device/1284090 new file mode 100644 index 000000000..ad4475957 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1288385 b/results/classifier/gemma3:12b/device/1288385 new file mode 100644 index 000000000..e3a2e5639 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1288385 @@ -0,0 +1,65 @@ + +VFIO passthrough causes assertation failure + +Since commit 5e95494380ec I am no longer able to passthrough my Nvidia GTX 770 using VFIO. Qemu terminates with: + +qemu-system-x86_64: hw/pci/pcie.c:240: pcie_cap_slot_hotplug_common: Assertion `((pci_dev->devfn) & 0x07) == 0' failed. + +Above output was generated using commit f55ea6297cc0. + + +Lspci of the vga card: + +01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1) + Subsystem: Gigabyte Technology Co., Ltd Device 360c + Kernel driver in use: vfio-pci +01:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1) + Subsystem: Gigabyte Technology Co., Ltd Device 360c + Kernel driver in use: vfio-pci + + +Commandline used to start qemu: + +qemu-system-x86_64 -machine accel=kvm \ + -nodefaults \ + -name VFIO-Test \ + -machine q35 \ + -cpu host \ + -smp 1 \ + -enable-kvm \ + -m 1024 \ + -k de \ + -vga none \ + -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ + -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ + -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 \ + -rtc base=utc \ + -boot order=d \ + -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0 \ + -drive file=/home/bluebird/Downloads/systemrescuecd-x86-4.0.0.iso,if=none,id=drive-cd-disk1,media=cdrom \ + -nographic + + +Full output of git bisect: + +5e95494380ecf83c97d28f72134ab45e0cace8f9 is the first bad commit +commit 5e95494380ecf83c97d28f72134ab45e0cace8f9 +Author: Igor Mammedov <email address hidden> +Date: Wed Feb 5 16:36:52 2014 +0100 + + hw/pci: switch to a generic hotplug handling for PCIDevice + + make qdev_unplug()/device_set_realized() to call hotplug handler's + plug/unplug methods if available and remove not needed anymore + hot(un)plug handling from PCIDevice. + + In case if hotplug handler is not available, revert to the legacy + hotplug method for compatibility with not yet converted buses. + + Signed-off-by: Igor Mammedov <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + +:040000 040000 9bdab0d75fbc9be4fe2e4274e58e0cdcd347ac7e d6d6294ea9c06e80a0fc8fcabd6345dfae5137ad M hw +:040000 040000 d064d75ca8b8f169c41eee2683082e8f9104e968 f2abbf9bee754ada0f49135968455fd1a69b2186 M include +:040000 040000 c515daff6c77f9bd2cc32873be4c5c3a1c20cbb9 c506f5587afe8f7ee129a7ca6e3ae2e5118254f9 M tests \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1290 b/results/classifier/gemma3:12b/device/1290 new file mode 100644 index 000000000..4d4f7667e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1290 @@ -0,0 +1,2 @@ + +IO alignment probing delivers incorrect results on Linux when used with e.g. dm-crypt diff --git a/results/classifier/gemma3:12b/device/1295587 b/results/classifier/gemma3:12b/device/1295587 new file mode 100644 index 000000000..38d781474 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1295587 @@ -0,0 +1,20 @@ + +Temporal freeze and slowdown while using emulated sb16 + +I have been carrying around this bug since previous versions and on different machines: When I use the -soundhw sb16 option, while playing any sound on the virtual machine it freezes and loops the last bit of such sound effect for 1-2 minutes, then goes back to normal speed. + +Console shows: + + sb16: warning: command 0xf9,1 is not truly understood yet + sb16: warning: command 0xf9,1 is not truly understood yet +(...) +main-loop: WARNING: I/O thread spun for 1000 iterations + +-One of my emulated machines is Windows 3.11: I managed to overrun this bug by switching from the local 1.5 version of the sound blaster driver to the 1.0, although since I updated qemu it freezes that machine, so I can't test if it still works. + +I am using the 1.7.90 version, but I suffered this bug for over one year + +this bug happens anytime I use the -soundhw sb16 switch, but the full command I am using in this specific case is: + + +qemu-system-i386 -localtime -cpu pentium -m 32 -display sdl -vga cirrus -hda c.img -cdrom win95stuff.iso -net nic,model=ne2k_pci -net user -soundhw sb16 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1296882 b/results/classifier/gemma3:12b/device/1296882 new file mode 100644 index 000000000..14c23ff46 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1296882 @@ -0,0 +1,6 @@ + +add next free device option to qemu-img + +I'd like to propose an option to be added to qemu-img which returns the next free NBD (the device file) very similar to losetup -f. It would make life a lot easier. + +Followers of this enhancement request might be interested in the following workaround: http://stackoverflow.com/questions/22535222/next-free-device-option-for-qemu-nbd/ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1298 b/results/classifier/gemma3:12b/device/1298 new file mode 100644 index 000000000..d7c21c277 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1298 @@ -0,0 +1,16 @@ + +virtio-pmem not working on microvm: virtio-pmem missing request data +Description of problem: +When using micorvm, qemu does not "connect" the memory backend mem1 with the pmem device. + +When using the first command is executed, qemu shows the following starts message: +``` +qemu-system-x86_64: virtio-pmem missing request data +``` + +and the kernel outputs following messages: +``` +[ 0.043871] nd_pmem namespace0.0: could not reserve region [mem 0x00000000-0x001fffff] +[ 0.043923] IPI shorthand broadcast: enabled +[ 0.044022] nd_pmem: probe of namespace0.0 failed with error -16 +``` diff --git a/results/classifier/gemma3:12b/device/1299566 b/results/classifier/gemma3:12b/device/1299566 new file mode 100644 index 000000000..89e7702b7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1299566 @@ -0,0 +1,12 @@ + +virtio serial doesn't work with virtio nic + +If virtio NIC is not used virtserialport works and delivers data written to /dev/vport0p1 to localhost:4444: + +qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic + +If using virtio nic, write to /dev/vport0p1 succeeds, but no data is delivered to localhost:4444: + +qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic,model=virtio + +This bug exists in 2.0 release, Debian's QEMU 1.7 package and b3706faf from git. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1300 b/results/classifier/gemma3:12b/device/1300 new file mode 100644 index 000000000..69ba14387 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1306818 b/results/classifier/gemma3:12b/device/1306818 new file mode 100644 index 000000000..d18ff66af --- /dev/null +++ b/results/classifier/gemma3:12b/device/1306818 @@ -0,0 +1,44 @@ + +resetting moder register in opencores_eth.c code (ethernet IP core specification code) + +Hi, I would like to report a possible error in the code qemu/hw/net/opencores_eth.c + +The corresponding data sheet : http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf + + +In the code, there is a function open_eth_moder_host_write. + +static void open_eth_moder_host_write(OpenEthState *s, uint32_t val) +{ + uint32_t set = val & ~s->regs[MODER]; + + if (set & MODER_RST) { + open_eth_reset(s); + } + + s->regs[MODER] = val; + + if (set & MODER_RXEN) { + s->rx_desc = s->regs[TX_BD_NUM]; + open_eth_notify_can_receive(s); + } + if (set & MODER_TXEN) { + s->tx_desc = 0; + open_eth_check_start_xmit(s); + } +} + +This piece of code is executed when MODER (Mode Register) resister is command to updated to ‘val’. + +In case of reset, as you can see, if the MODER_RST bit (0x800) bit is set && the old MODER_RST bit (0x800) of MODER register is clear, the code falls into the if(set & MODER_RST) branch. Then, it calls open_eth_reset(s), which does “s->regs[MODER] = 0xa000;”. Now, the MODER register is reset to 0xa000. Page 9 of the data sheet (http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf) specifies the reset value of the moder is 0000A000h. So far, the code works fine. +Then, the open_eth_moder_host_write function does not end but executes but executes “s->regs[MODER] = val;” line. Now, the MODER register is not 0xa000 any more. +In fact, since the MODER_RST bit of ‘val’ is 1, now the MODER_RST bit of the MODER register becomes 1 as well. Suppose one somehow calls this open_eth_moder_host_write again with val = MODER_RST with purpose of resetting again. Since the MODER_RST bit is 1, (set = val & ~s->regs[MODER]) & MODER_RST is zero. So after this, resetting again is not possible. + +Hence, I doubt the function’s correctness here. I think it could be better if the function changes to : + + if (set & MODER_RST) { + open_eth_reset(s); + return; + } + +Please let me know if I am correct. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1309 b/results/classifier/gemma3:12b/device/1309 new file mode 100644 index 000000000..c7f20691e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1309 @@ -0,0 +1,2 @@ + +Heap-overflow in virtio_net_queue_enable diff --git a/results/classifier/gemma3:12b/device/1314 b/results/classifier/gemma3:12b/device/1314 new file mode 100644 index 000000000..8ff4ba7d2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1314 @@ -0,0 +1,41 @@ + +68k: issues with fremx and fmodx +Description of problem: +Some of the mac68k folks have been testing my MacOS branch at https://github.com/mcayland/qemu/tree/q800.upstream2-vm and noticed problems with the values of some of the MacOS _Pack5 transcendental functions. This is easily visible when calling the `sin()` and `cos()` functions whereby some angle ranges use the values from the wrong section of the waveform and/or return values with the incorrect sign. + +SolraBizna was kind enough to write a 68K MacOS test program to generate a sine table (including dumping the hex values of the FP registers) that could be run on real hardware for comparison with QEMU. Using this it was discovered that the issue is related to the implementation of the `fremx` and `fmodx` instructions which can be found in [`floatx80_modrem()`](https://gitlab.com/qemu-project/qemu/-/blob/master/fpu/softfloat.c#L2601). + +I have taken the output of the test program run on a real 68040 Mac and used it to create a test harness at https://github.com/mcayland/qemu/commits/68k-fmodrem-bug [(diff from git master)](https://github.com/mcayland/qemu/commit/4afd6b7c3cad89df943ec43395f95dad7f368338.diff) which iterates over 100 points of the sine table and uses the registers to indicate any failures according to the following comment: + +``` + /* + * The test program below hangs when it completes and the exit + * condition can be determined using the monitor via "info + * registers" command as follows: + * + * D7 is the test number (0-99) + * D6 is the error code + * 0 = no error + * 1 = frem result incorrect + * 2 = frem fpsr result incorrect + * 3 = fmod result incorrect + * 4 = fmod fpsr result incorrect + * D2 is the actual result of the long comparison + * D1 is the expected result of the long comparison + * + * A successful termination of the test program is when D7 == 100 + * and D6 == 0. + */ +``` + +This enables the majority of debugging to be done directly using `info registers` in the monitor rather than manually stepping through the example code using the gdbstub. + +Based upon my local testing on `qemu-system-m68k` there are 2 main differences between QEMU and the output from a real 68040: + +- Differences in precision + +The very first `fremx` result comparison fails here returning `0x3ffe0000 0xc90fdaa2 0x2168c23c 0x........` instead of `0x3ffe0000 0xc90fdaa2 0x2168c238 0x........`. Fortunately the difference in precision is small, and while it may not be possible to fix this, at least it gives a measure of how QEMU's emulation compares to a real 68040. + +- Incorrect setting of the quotient byte + +Bits 16-23 of the FPSR are supposed to contain the sign and 7 LSBs of the quotient for `fremx` and `fmodx` instructions, which is used in _Pack5 to generate an offset into a lookup table for the transcendental functions. It appears that the main cause of the incorrect `sin()` and `cos()` functions is due to the quotient byte being set incorrectly by `fremx`, causing MacOS to jump to the wrong segment of the lookup table for certain angle ranges. diff --git a/results/classifier/gemma3:12b/device/1314293 b/results/classifier/gemma3:12b/device/1314293 new file mode 100644 index 000000000..00b74f8a8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1314293 @@ -0,0 +1,8 @@ + +screendump with qxl + spice shows stale data + +The monitor 'screendump' command returns stale data for VMs using qxl + spice. If you perform multiple screendumps, screendump #N will show roughly the display from the time screendump #N-1 was taken. This affects 'virsh screenshot' and libvirt screenshot APIs by association. + +Gerd explains that new monitor commands/infrastructure is likely required to handle this correctly: + +https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03840.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1314857 b/results/classifier/gemma3:12b/device/1314857 new file mode 100644 index 000000000..bc359352d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1314857 @@ -0,0 +1,20 @@ + +seg fault in ivshmem when using ioeventfd=on + +When launching qemu with the ivshmem device and the nahanni guest server there is segmentation fault in the setup_ioeventfds function of ivshmem.c. If the ioeventfd=on flag is set the pci_ivshmem_init will call setup_ioeventfds at line 668. This function relies on the 'peers' member of the server info which is not allocated until line 669. + +To reproduce you will need the nahanni guest server code. The driver code is not needed. You will also need a qcow2 or other bootable image to use for launching qemu. The error occurs before the actual image launch. + +Start the nahanni ivshmem server with a small global memory space ( although the bug is not allocation specific ) +ivshmem -m 1 -n 2 -p /tmp/ivshmem_socket + +Next launch qemu with initialization for the ivshmem device. +qemu-system-x86_64 -hda test_iso.qcow2 -localtime -boot c -chardev socket,path="/tmp/ivshmem_socket",id=ivshmem_socket -device ivshmem,chardev=ivshmem_socket,size=1,ioeventfd=on + +If gdb is used the following error is recorded: +Program received signal SIGSEGV, Segmentation fault. +0x000055555579dd52 in setup_ioeventfds (s=0x555556619580) + at /home/genes/work/ubuntu/qemu-kvm-1.0+noroms/hw/ivshmem.c:367 +367 for (j = 0; j < s->peers[i].nb_eventfds; j++) { +(gdb) print s->peers +$2 = (Peer *) 0x0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1318 b/results/classifier/gemma3:12b/device/1318 new file mode 100644 index 000000000..7581c4404 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1318 @@ -0,0 +1,20 @@ + +vsock device fails with "qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)" when queue_reset=true +Description of problem: +Immediately after guest vsock driver initialize, qemu prints error messages. I'm not able to connect to the guest with vsock: + +``` +[ 0.654463] Run /init as init process +[ 0.679778] NET: Registered PF_VSOCK protocol family +qemu-system-x86_64: vhost_set_features failed: Operation not supported (95) +qemu-system-x86_64: Error starting vhost: 95 +ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 +# +``` +Steps to reproduce: +1. Clone `git://passt.top/passt` +2. In `passt/test`, run `make mbuto.img` +3. Run `qemu-system-x86_64 -enable-kvm -m 2048 -kernel KERNEL -initrd mbuto.img -nographic -serial stdio -nodefaults -append "console=ttyS0" -device vhost-vsock-pci,guest-cid=31415,queue_reset=true` replacing KERNEL with the host kernel image. +Additional information: +- Problem goes away if `queue_reset=false`, which means it goes away with default options prior to `69e1c14aa222` ("virtio: core: vq reset feature negotation support") +- Occurs both with and without KVM diff --git a/results/classifier/gemma3:12b/device/133 b/results/classifier/gemma3:12b/device/133 new file mode 100644 index 000000000..e2b3e6e90 --- /dev/null +++ b/results/classifier/gemma3:12b/device/133 @@ -0,0 +1,2 @@ + +Chardev websocket might not support pasting more than a few chars diff --git a/results/classifier/gemma3:12b/device/1332234 b/results/classifier/gemma3:12b/device/1332234 new file mode 100644 index 000000000..2ceda31bc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1332234 @@ -0,0 +1,11 @@ + +qemu-system-ppc no longer able to read real cdrom + +When I use to send the -cdrom /dev/cdrom option to QEMU, I would be able to use a real cdrom. With QEMU v2.0.0, real cdroms don't work. A quick look at the output from the "info block" command shows this: + +ide1-cd0: /dev/cdrom (raw, read-only) + Removable device: not locked, tray closed + +This indicates that the cdrom is set to /dev/cdrom. I remember versions of QEMU prior to 1.5 were able to use a real cdrom. + +qemu-system-ppc is being run on Mac OS 10.6.8. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1333216 b/results/classifier/gemma3:12b/device/1333216 new file mode 100644 index 000000000..502061970 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1333688 b/results/classifier/gemma3:12b/device/1333688 new file mode 100644 index 000000000..064495cf1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1336 b/results/classifier/gemma3:12b/device/1336 new file mode 100644 index 000000000..bc5d8cee0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1336 @@ -0,0 +1,2 @@ + +QEMU qxl_phys2virt Unsafe Address Translation Lead to OOB Read diff --git a/results/classifier/gemma3:12b/device/1336123 b/results/classifier/gemma3:12b/device/1336123 new file mode 100644 index 000000000..86bbfff7e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1336123 @@ -0,0 +1,12 @@ + +bad switch, segfault in hw/pci-host/bonito.c bonito_readl + +http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci-host/bonito.c;h=56292adb03cd1a9873c2c9e5a0b2978fd0572214;hb=master#l301 + +The switch statement is error-prone, since two branches return the same result. + +Segfault reproducing steps: +1. make a Linux kernel(for example 3.16.0-rc2) with fuloong2e_defconfig +2. use 'qemu-system-mips64el -machine fulong2e' to boot the vmlinux + +qemu versions tried: 2.0.0, 1.6.2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1336192 b/results/classifier/gemma3:12b/device/1336192 new file mode 100644 index 000000000..ca9320f0e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1336192 @@ -0,0 +1,6 @@ + +delvm does not delete snapshots on every disks + +Using more than one block device, using delvm does remove snapshot from the first block device, but does not remove snapshots from other blockdevs (complains about not finding snapshot on 1st blockdev). + +Attached patch fixes that. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1342 b/results/classifier/gemma3:12b/device/1342 new file mode 100644 index 000000000..7af9e0440 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1342 @@ -0,0 +1,25 @@ + +Default machine setting of force-legacy=true causes problems for any modern VirtIO device using MMIO +Description of problem: +The default causes problems if you enable any non-legacy VirtIO device which has the VIRTIO_F_VERSION_1 feature bit will not properly read all feature bits. This is because reading VIRTIO_MMIO_VERSION returns VIRT_VERSION_LEGACY which in turn results in the driver not reading all feature bits, e.g. the qtest access: + +``` +static uint64_t qvirtio_mmio_get_features(QVirtioDevice *d) +{ + QVirtioMMIODevice *dev = container_of(d, QVirtioMMIODevice, vdev); + uint64_t lo; + uint64_t hi = 0; + + qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 0); + lo = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES); + + if (dev->version >= 2) { + qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 1); + hi = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES); + } + + return (hi << 32) | lo; +} +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1343 b/results/classifier/gemma3:12b/device/1343 new file mode 100644 index 000000000..8e76ea4ca --- /dev/null +++ b/results/classifier/gemma3:12b/device/1343 @@ -0,0 +1,37 @@ + +qemu-system-riscv64: It cannot initialize ramfb video adapter +Description of problem: +It looks like ramfb video adapter doesn't work in riscv64 architecture. But it works fine in aarch64 architecture. +Steps to reproduce: +1. Launch the [attached kernel](/uploads/43282fa1bd6959472af4f99646b447b9/kernel) with command: +``` +qemu-system-riscv64 -machine virt -kernel kernel -device ramfb -bios none -serial stdio +``` +2. You will get the messages in console: +``` +guest fw_cfg dma-interface enabled +setup ramfb successfull +``` +3. Video adapter will not initialize. QEMU window will continue display this message: +``` +Guest has not initialized the display (yet). +``` +Additional information: +There is a useful project for aarch64 architecture - https://github.com/luickk/qemu-ramfb-aarch64-driver. This is a Bare metal driver for ramfb adapter. It works fine. I adapted it for riscv64 architecture - https://github.com/CityAceE/qemu-ramfb-riscv64-driver. I've successfully went through all problems. Driver compiles now and launches. But unfortunately ramfb doesn't initialize. I parallel traced aarch64 and riscv64. They works equal until initialization. Aarch64 changes revolution just after qemu_cfg_write_entry call, but nothing happened after qemu_cfg_write_entry call in riscv64 emulation. I spent a lot of time trying to resolve this problem, but it looks like a problem in qemu-system-riscv64. + +**UPDATE** + +Tested with Windows builds of QEMU: + +v 6.1 - The same situation as Ubuntu build 6.2. + +v 7.1.92 - Stopped with message: +``` +c:\Program Files\qemu\qemu-system-riscv64.exe: -device ramfb: ramfb device requires fw_cfg with DMA +``` + +P.S. v 7.1.92 - qemu-system-aarch64.exe with [aarch64 kernel build](/uploads/0df1d440163913c25a1505032672e1c5/kernel) works fine. + +**UPDATE2** + +[QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)](https://qemu.weilnetz.de/w64/2022/qemu-w64-setup-20220419.exe) is the last Windows build which opens my riscv64 kernel without message about requirement of fw_cfg with DMA. Next build "QEMU emulator version 7.0.90 (v7.1.0-rc0-11915-g5f9b281b8a-dirty)" already has this issue. diff --git a/results/classifier/gemma3:12b/device/1343827 b/results/classifier/gemma3:12b/device/1343827 new file mode 100644 index 000000000..2d4a410a5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1352 b/results/classifier/gemma3:12b/device/1352 new file mode 100644 index 000000000..86414ed4a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1352 @@ -0,0 +1,2 @@ + +Building hw-display-virtio-*-gl modules with empty source set diff --git a/results/classifier/gemma3:12b/device/1352465 b/results/classifier/gemma3:12b/device/1352465 new file mode 100644 index 000000000..b746158f7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1352465 @@ -0,0 +1,8 @@ + +Can't install virtio block drivers during Windows setup + +Hi! +Apparently there's no way to install the virtio block drivers during Windows setup, as they're simply not recognized by the installer when it looks for them on the CD drive. +The only way to setup virtio block drivers is to first install Windows on a IDE drive, then add a dummy virtio disk, then load the drivers and swap the two disks. +I'm using virtio-win-0.1-81.iso. I can confirm the issue with Windows Server 2012 R2 and Windows 7 Professional, 64 bit. +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1354 b/results/classifier/gemma3:12b/device/1354 new file mode 100644 index 000000000..d812fdaf1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1354 @@ -0,0 +1,2 @@ + +-device usb-tablet not working on android guest. diff --git a/results/classifier/gemma3:12b/device/1356 b/results/classifier/gemma3:12b/device/1356 new file mode 100644 index 000000000..dae7eacb2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1356 @@ -0,0 +1,18 @@ + +"-set device" doesn't work with device specified in json +Description of problem: +The above QEMU command line results in: +``` +qemu-system-x86_64: -set device.ua-igd.x-igd-gms=1: there is no device "ua-igd" defined +``` +While the following command works: +``` +qemu-system-x86_64 -accel kvm -m 8192 -nodefaults -display none -net none -device vfio-pci,host=0000:00:02.0,id=ua-igd -set device.ua-igd.x-igd-gms=1 +``` +libvirt has moved to the json device specification, therefore I can no longer associate use a <qemu:commandline> section to set driver options for a specific device with this broken id association. +Steps to reproduce: +1. Create a device with an ID and use -set device.$ID to set a driver option for the device +2. Note failure when using json device format vs legacy device specification +3. Profit +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1358722 b/results/classifier/gemma3:12b/device/1358722 new file mode 100644 index 000000000..32727f567 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1359394 b/results/classifier/gemma3:12b/device/1359394 new file mode 100644 index 000000000..d3ea2c846 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1359394 @@ -0,0 +1,12 @@ + +virtio block device hangs after "virtio_blk virtio3: requests:id 0 is not a head!" + +The virtual machine is running block layer workloads, interrupted by unclean reboots (echo b > /proc/sysrq-trigger). Kernel version is 3.14. + +Sometimes, I get this message on boot: + +"virtio_blk virtio3: requests:id 0 is not a head!" + +Then, I/O to the virtio block devices just hangs. + +Unfortunately I don't have a test case and this is kind of hard to reproduce, but it seems related to having I/O in flight when the kernel is forced to reboot. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1367 b/results/classifier/gemma3:12b/device/1367 new file mode 100644 index 000000000..69e1dcfc6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1368 b/results/classifier/gemma3:12b/device/1368 new file mode 100644 index 000000000..83cf2af0f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1368 @@ -0,0 +1,39 @@ + +unexpect rax value +Description of problem: +- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. +Steps to reproduce: +- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax + 0x2206 <vga_init+16>: movq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8: 0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1368178 b/results/classifier/gemma3:12b/device/1368178 new file mode 100644 index 000000000..278cfc5ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/1368178 @@ -0,0 +1,26 @@ + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 + +A fresh installation of Windows Millennium Edition (Windows ME, WinME) as guest OS on qemu interprets qemu's videocards as Number Nine Imagine 128 with the consequence, that + +1. It is impossible to change color depth. +2. WinME uses the i128.drv Driver that is shipped with WinMe. +3. Forcing WinME to use other drivers has no effect. + + +It also doesn't matter what option for -vga was given to QEMU at command line. +cirrus, std, vmware, qxl etc. all have no effect, the videocard detected by Windows Me stays at Number Nine Imagine 128. + +Even selecting another driver in WinME and forcing WinME to use drivers such as the Cirrus Logic 5446 PCI driver has no effect. + +I also want to mention, that the BIOS isn't detected by WinME properly. +The device manager of WinME shows errors with the Plug & Play BIOS driver BIOS.vxd. + + +That is the QEMU Version: + +# qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard + +And this was the complete command line, that was given: +# sudo /usr/bin/qemu-system-i386 -hda WinME_QEMU.img -cdrom drivers.iso -boot c -no-acpi -no-hpet -soundhw sb16 -net nic -cpu pentium3 -m 256 -vga cirrus \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1369347 b/results/classifier/gemma3:12b/device/1369347 new file mode 100644 index 000000000..a856d51c1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1369347 @@ -0,0 +1,19 @@ + +Mac OS X cannot passthrough USB device to guest + +I'm using Mac OS 10.9.4 with qemu-system-arm installed from brew (version 1.7.1) and verified with qemu-system-x86_64. I'm trying to pass a Ralink 5370 WiFi USB dongle to my guest system, it appears in my system profiler as: + +802.11 n WLAN: + + Product ID: 0x5370 + Vendor ID: 0x148f + Version: 1.01 + Serial Number: 1.0 + Speed: Up to 480 Mb/sec + Manufacturer: Ralink + Location ID: 0x1d110000 / 6 + Current Available (mA): 500 + Current Required (mA): 450 + +Using the docs, I'm passing "-usb -device usb-host,vendorid=0x148f,productid=0x5370" and getting this error back: +"qemu-system-arm: -device usb-host,vendorid=0x148f,productid=0x5370: Parameter 'driver' expects device type" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1377163 b/results/classifier/gemma3:12b/device/1377163 new file mode 100644 index 000000000..134f783be --- /dev/null +++ b/results/classifier/gemma3:12b/device/1377163 @@ -0,0 +1,8 @@ + +Does not add usb-host devices as they are hotplugged + +A commandline such as + +qemu-kvm -device usb-ehci,id=USBCtrl -device host-usb,bus=USBCtrl.0,hostbus=3 + +should automatically add all devices on the given bus (here: 3) not only initially, but also when new devices appear on that bus while Qemu runs. Currently, all devices on the bus are added initially, but new devices which are added to the (host) usb while Qemu runs have to be added manually. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1378407 b/results/classifier/gemma3:12b/device/1378407 new file mode 100644 index 000000000..c6acf687e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1378407 @@ -0,0 +1,6 @@ + +[feature request] Partition table wrapper for single-filesystem images + +Suppose you have a single filesystem image. It would be nice if QEMU could generate a virtual partition table for it and make it available to the guest as a partitioned disk. Otherwise you have to use workarounds like this: wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID + +It should be relatively easy to do on top of existing vvfat code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1378554 b/results/classifier/gemma3:12b/device/1378554 new file mode 100644 index 000000000..91f28f5c5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1378554 @@ -0,0 +1,176 @@ + +qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit + +/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \ + -global virtio-blk-device.scsi=off \ + -nodefconfig \ + -enable-fips \ + -nodefaults \ + -display none \ + -M virt \ + -machine accel=kvm:tcg \ + -m 500 \ + -no-reboot \ + -rtc driftfix=slew \ + -global kvm-pit.lost_tick_policy=discard \ + -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1001/appliance.d/kernel \ + -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1001/appliance.d/initrd \ + -device virtio-scsi-device,id=scsi \ + -drive file=/home/rjones/d/libguestfs/tmp/libguestfseV4fT5/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ + -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1001/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \ + -device scsi-hd,drive=appliance \ + -device virtio-serial-device \ + -serial stdio \ + -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfseV4fT5/guestfsd.sock,id=channel0 \ + -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ + -append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=6000 no_timer_check lpj=4464640 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color' + +The appliance boots, but segfaults as soon as the virtio-scsi driver is loaded: + +supermin: internal insmod virtio_scsi.ko +[ 3.992963] scsi0 : Virtio SCSI HBA +libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages + +I captured a core dump: + +Core was generated by `/home/rjones/d/qemu/arm-softmmu/qemu-system-arm -global virtio-blk-device.scsi='. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x000856bc in virtio_scsi_handle_cmd_req_submit (s=<optimized out>, + req=0x6c03acf8) at /home/rjones/d/qemu/hw/scsi/virtio-scsi.c:551 +551 bdrv_io_unplug(req->sreq->dev->conf.bs); +(gdb) bt +#0 0x000856bc in virtio_scsi_handle_cmd_req_submit (s=<optimized out>, + req=0x6c03acf8) at /home/rjones/d/qemu/hw/scsi/virtio-scsi.c:551 +#1 0x0008573a in virtio_scsi_handle_cmd (vdev=0xac4d68, vq=0xafe4b8) + at /home/rjones/d/qemu/hw/scsi/virtio-scsi.c:573 +#2 0x0004fdbe in access_with_adjusted_size (addr=80, + value=value@entry=0x4443e6c0, size=size@entry=4, access_size_min=1, + access_size_max=<optimized out>, access_size_max@entry=0, + access=access@entry=0x4fee9 <memory_region_write_accessor>, + mr=mr@entry=0xa53fa8) at /home/rjones/d/qemu/memory.c:480 +#3 0x00054234 in memory_region_dispatch_write (size=4, data=2, + addr=<optimized out>, mr=0xa53fa8) at /home/rjones/d/qemu/memory.c:1117 +#4 io_mem_write (mr=0xa53fa8, addr=<optimized out>, val=val@entry=2, + size=size@entry=4) at /home/rjones/d/qemu/memory.c:1958 +#5 0x00021c88 in address_space_rw (as=0x3b96b4 <address_space_memory>, + addr=167788112, buf=buf@entry=0x4443e790 "\002", len=len@entry=4, + is_write=is_write@entry=true) at /home/rjones/d/qemu/exec.c:2135 +#6 0x00021de6 in address_space_write (len=4, buf=0x4443e790 "\002", + addr=<optimized out>, as=<optimized out>) + at /home/rjones/d/qemu/exec.c:2202 +#7 subpage_write (opaque=<optimized out>, addr=<optimized out>, value=2, + len=4) at /home/rjones/d/qemu/exec.c:1811 +#8 0x0004fdbe in access_with_adjusted_size (addr=592, + value=value@entry=0x4443e820, size=size@entry=4, access_size_min=1, + access_size_max=<optimized out>, access_size_max@entry=0, + access=access@entry=0x4fee9 <memory_region_write_accessor>, + mr=mr@entry=0xaed980) at /home/rjones/d/qemu/memory.c:480 +#9 0x00054234 in memory_region_dispatch_write (size=4, data=2, + addr=<optimized out>, mr=0xaed980) at /home/rjones/d/qemu/memory.c:1117 +#10 io_mem_write (mr=0xaed980, addr=<optimized out>, val=2, size=size@entry=4) + at /home/rjones/d/qemu/memory.c:1958 +#11 0x00057f24 in io_writel (retaddr=1121296542, Cannot access memory at address 0x0 +addr=<optimized out>, val=2, + physaddr=592, env=0x9d6c50) at /home/rjones/d/qemu/softmmu_template.h:381 +#12 helper_le_stl_mmu (env=0x9d6c50, addr=<optimized out>, val=2, + mmu_idx=<optimized out>, retaddr=1121296542) + at /home/rjones/d/qemu/softmmu_template.h:419 +#13 0x42d5a0a0 in ?? () +Cannot access memory at address 0x0 +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) print req +$1 = (VirtIOSCSIReq *) 0x6c03acf8 +(gdb) print req->sreq +$2 = (SCSIRequest *) 0xc2c2c2c2 +(gdb) print req->sreq->dev +Cannot access memory at address 0xc2c2c2c6 +(gdb) print *req +$3 = { + dev = 0x6c000040, + vq = 0x6c000040, + qsgl = { + sg = 0x0, + nsg = 0, + nalloc = -1027423550, + size = 3267543746, + dev = 0xc2c2c2c2, + as = 0xc2c2c2c2 + }, + resp_iov = { + iov = 0xc2c2c2c2, + niov = -1027423550, + nalloc = -1027423550, + size = 3267543746 + }, + elem = { + index = 3267543746, + out_num = 3267543746, + in_num = 3267543746, + in_addr = {14033993530586874562 <repeats 1024 times>}, + out_addr = {14033993530586874562 <repeats 1024 times>}, + in_sg = {{ + iov_base = 0xc2c2c2c2, + iov_len = 3267543746 + } <repeats 1024 times>}, + out_sg = {{ + iov_base = 0xc2c2c2c2, + iov_len = 3267543746 + } <repeats 1024 times>} + }, + vring = 0xc2c2c2c2, + { + next = { + tqe_next = 0xc2c2c2c2, + tqe_prev = 0xc2c2c2c2 + }, + remaining = -1027423550 + }, + sreq = 0xc2c2c2c2, + resp_size = 3267543746, + mode = (SCSI_XFER_TO_DEV | unknown: 3267543744), + resp = { + cmd = { + sense_len = 3267543746, + resid = 3267543746, + status_qualifier = 49858, + status = 194 '\302', + response = 194 '\302' + }, + tmf = { + response = 194 '\302' + }, + an = { + event_actual = 3267543746, + response = 194 '\302' + }, + event = { + event = 3267543746, + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + reason = 3267543746 + } + }, + req = { + { + cmd = { + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + tag = 14033993530586874562, + task_attr = 194 '\302', + prio = 194 '\302', + crn = 194 '\302' + }, + cdb = 0x6c042d73 '\302' <repeats 36 times>, <incomplete sequence \302> + }, + tmf = { + type = 3267543746, + subtype = 3267543746, + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + tag = 14033993530586874562 + }, + an = { + type = 3267543746, + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + event_requested = 3267543746 + } + } +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1382477 b/results/classifier/gemma3:12b/device/1382477 new file mode 100644 index 000000000..a992fc3ed --- /dev/null +++ b/results/classifier/gemma3:12b/device/1382477 @@ -0,0 +1,16 @@ + +hw/i386/intel_iommu.c:902: wrong logical operator ? + +/home/dcb/qemu/trunk/qemu/hw/i386/intel_iommu.c:902:5: error: logical ‘and’ applied to non-boolean constant [-Werror=logical-op] + pvtd_as = s->address_spaces[VTD_SID_TO_BUS(source_id)]; + ^ + +$ fgrep VTD_SID_TO_BUS `find . -name \*.h -print` +./include/hw/i386/intel_iommu.h:#define VTD_SID_TO_BUS(sid) (((sid) >> 8) && 0xff) +$ + +Sounds to me like + +#define VTD_SID_TO_BUS(sid) (((sid) >> 8) & 0xff) + +would be better. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1385934 b/results/classifier/gemma3:12b/device/1385934 new file mode 100644 index 000000000..23eff5097 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1385934 @@ -0,0 +1,29 @@ + +USB with passthrougth guest cannot enumerate USB host + +Following the guide at http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest +Qemu is launched with qemu-system-x86_64 /dev/vgstripe/kvm_wifi -enable-kvm -m 512 -k fr -net nic -net tap,ifname=tap1,script=/bin/ifup.script -kernel /usr/src/linux_git/arch/x86_64/boot/bzImage -append root=/dev/sda -usb -device usb-host,hostbus=1,hostaddr=6 +The USB device does not show and USB stack seems not working +On the guest: +dmesg |grep -i usb +[ 1.416966] hub 1-0:1.0: USB hub found +[ 1.420431] usbcore: registered new interface driver usb-storage +[ 1.445374] usbcore: registered new interface driver usbhid +[ 1.446839] usbhid: USB HID core driver +[ 1.863226] usb 1-1: new low-speed USB device number 2 using uhci_hcd +[ 2.126173] usb 1-1: Invalid ep0 maxpacket: 64 +[ 2.373161] usb 1-1: new low-speed USB device number 3 using uhci_hcd +[ 2.648112] usb 1-1: Invalid ep0 maxpacket: 64 +[ 2.892404] usb 1-1: new low-speed USB device number 4 using uhci_hcd +[ 2.913001] usb 1-1: Invalid ep0 maxpacket: 64 +[ 3.161367] usb 1-1: new low-speed USB device number 5 using uhci_hcd +[ 3.180070] usb 1-1: Invalid ep0 maxpacket: 64 +[ 3.181633] usb usb1-port1: unable to enumerate USB device +lsusb +Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +On the host: +lsusb +Bus 001 Device 006: ID 0457:0163 Silicon Integrated Systems Corp. SiS163U 802.11 Wireless LAN Adapter +qemu-system-x86_64 --version +QEMU emulator version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1391 b/results/classifier/gemma3:12b/device/1391 new file mode 100644 index 000000000..6dbfe010d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1392504 b/results/classifier/gemma3:12b/device/1392504 new file mode 100644 index 000000000..08867cb5b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1392504 @@ -0,0 +1,4 @@ + +libvirt not relabeling devices on USB Passthrough + +After upgrading from Ubuntu 14.04 to Ubuntu 14.10 USB passthrough in QEMU (version is now 2.1.0 - Debian2.1+dfsg-4ubuntu6.1) is not working any more. Already tried to remove and attach the USB devices. I use 1 USB2 HDD + 1 USB3 HDD to a virtual linux machine; 1 USB2 HDD to a virual FNAS machine and a USB 2camera to virtual Win7 machine. All these devices are not working any more. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1393 b/results/classifier/gemma3:12b/device/1393 new file mode 100644 index 000000000..85cd7cb3c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1393 @@ -0,0 +1,66 @@ + +Abort in audio_calloc() of ac97 +Description of problem: +Section 5.10.2 of the AC97 specification (https://hands.com/~lkcl/ac97_r23.pdf) +shows the feasibility to support for rates other than 48kHZ. Specifically, +AC97_PCM_Front_DAC_Rate (reg 2Ch) should be from 8kHZ to 48kHZ. + + +An adversary can leverage this to crash QEMU. + +A nornal 48kHZ setting is like this. + +``` +ac97_realize + open_voice + as->freq = 0xbb80 # 0xbb80=48000 + AUD_open_out + audio_pcm_create_voice_pair_out (sw is NULL) + audio_pcm_sw_init_out + sw->info.freq = as->freq (in audio_pcm_init_info()) + sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq + samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out()) +``` + +A non-48kHZ setting is like this. Since `as->freq` is too small, `sw->ratio` is +too large. Finally, `samples` is zero, failing the audio_calloc() in +audio_pcm_sw_alloc_resources_out(). + +``` +nam_writew + open_voice + as->freq = 0x6 + AUD_open_out + audio_pcm_sw_init_out (sw is not NULL) + sw->info.freq = as->freq (in audio_pcm_init_info()) + sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq + samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out()) + audio_calloc(.., samples, ) (in audio_pcm_sw_alloc_resources_out()) +``` +Steps to reproduce: +1. download the prepared rootfs and the image. + + https://drive.google.com/file/d/1IfVCvn76HY-Eb4AZU7yvuyPzM3QC1q10/view?usp=sharing + https://drive.google.com/file/d/1JN6JgvOSI5aSLIdTEFKiskKbrGWFo0BO/view?usp=sharing + +2. run the following script. + +``` bash +QEMU_PATH=../../../qemu-devel/build/x86_64-softmmu/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -device ac97,audiodev=snd0 -audiodev none,id=snd0 \ + -nographic +``` + +3. with spawned shell (the user is root and the password is empty), run +`ac97-00`. +Additional information: +In the latest QEMU, this issue was generally fixed by 12f4abf6a245c43d8411577fd400373c85f08c6b and 0cbc8bd4694f32687bf47c6da48efa48fac35fd2 that remove abort() from the source code. Even though, I still plan to send a +patch so that the warning about the invalid freq will be gone. diff --git a/results/classifier/gemma3:12b/device/1393440 b/results/classifier/gemma3:12b/device/1393440 new file mode 100644 index 000000000..c642e0cca --- /dev/null +++ b/results/classifier/gemma3:12b/device/1393440 @@ -0,0 +1,18 @@ + +pcie.c:148: possible error in OR expression ? + +[qemu/hw/pci/pcie.c:148] -> [qemu/hw/pci/pcie.c:148]: (style) Same expression on both sides of '|'. + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_URD | PCI_EXP_DEVSTA_URD); + +I am guessing that something like + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD); + +was intended. + +I used static analyser cppcheck to find this bug. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1393486 b/results/classifier/gemma3:12b/device/1393486 new file mode 100644 index 000000000..fc2f03afb --- /dev/null +++ b/results/classifier/gemma3:12b/device/1393486 @@ -0,0 +1,16 @@ + +hw/virtio/virtio-rng.c:150: bad test ? + +hw/virtio/virtio-rng.c:150:31: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] + + if (!vrng->conf.period_ms > 0) { + error_setg(errp, "'period' parameter expects a positive integer"); + return; + } + +Maybe better code + + if (vrng->conf.period_ms <= 0) { + error_setg(errp, "'period' parameter expects a positive integer"); + return; + } \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1400768 b/results/classifier/gemma3:12b/device/1400768 new file mode 100644 index 000000000..6a00e0085 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1400768 @@ -0,0 +1,71 @@ + +Fatal error when running with '-machine isapc' on 2.1.2 + +all I have are the traces, should hopefully be easy to reproduce. + +# qemu-system-i386 -machine isapc +VNC server running on `::1:5900' +qemu: fatal: Trying to execute code outside RAM or ROM at 0x1a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000000 CCD=00000000 CCO=ADDB +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +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=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +Aborted + + +# qemu-system-x86_64 -machine isapc +VNC server running on `::1:5900' +qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000001a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=ADDB +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +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=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +Aborted \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1402289 b/results/classifier/gemma3:12b/device/1402289 new file mode 100644 index 000000000..b15dd1e1c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1402289 @@ -0,0 +1,11 @@ + +netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49 + +Subj. + +This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 installer. + +Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +Linux kernel: 3.17.6 and 3.18.0. + +Debug log for machine in the attachment. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1404 b/results/classifier/gemma3:12b/device/1404 new file mode 100644 index 000000000..8209ea850 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1404 @@ -0,0 +1,15 @@ + +qemu-7.2: virtio-blk-pci I/O errors with detect-zeroes=unmap +Description of problem: +Since upgrading from qemu-7.1 to qemu-7.2 I have seen many anomalies with VMs that use the virtio-blk-pci device for the root filesystem and the `detect-zeroes=unmap` option, typically in the form of I/O errors or huge decreases in read/write performance. This has been observed for both pre-existing Linux & Windows systems using the QCOW2 disk format, and a freshly created Linux system. + +* For an existing x86_64 Windows-10 guest system, hosted on Debian-11, the guest system takes many minutes to boot and Task Manager shows the virtual disk showing read/write latencies measured in seconds rather than milliseconds. +* Attempts to create a new x86_64 Debian-11 guest on a Debian-11 host produce an input/output error when trying to partition the QCOW2 hard disk /dev/vda (as per attached screenshot)  +* Using a pre-existing Debian-11 guest that works perfectly with qemu-7.1, fails to format a basic ext3 /dev/loop filesystem when this guest is booted with qemu-7.2, giving `mke2fs: Input/output error while writing out and closing file system` +Steps to reproduce: +(installer error) +1. Create fresh QCOW2 image: `qemu-img create -f qcow2 deb11.img 8G` +2. Run standard Debian-11 installer from ISO image and virtio-blk-pci drive and options `-drive if=none,media=disk,id=drive0,file=deb11.img,cache=writeback,discard=unmap,detect-zeroes=unmap` +3. Use default options with "guided partitioning" +Additional information: +I'm not aware of any changes to the setup of my system that would account for these problems, and have successfully tried many similar experiments with QEMU version up to and including version 7.1. Obviously, I'm hoping there's some trivial configuration error I've overlooked in qemu-7.2 - any suggestions would be much appreciated. diff --git a/results/classifier/gemma3:12b/device/1406 b/results/classifier/gemma3:12b/device/1406 new file mode 100644 index 000000000..a8b9cfd58 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1406 @@ -0,0 +1,2 @@ + +WANTED: Schematics, Service, Tech Notes, .pdf IBM Power4 970MP/FX Apple PowerMac G5 Early/Late 2005 diff --git a/results/classifier/gemma3:12b/device/1407 b/results/classifier/gemma3:12b/device/1407 new file mode 100644 index 000000000..4ec74d5a3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1407 @@ -0,0 +1,77 @@ + +Assertion failure in fimd_update_memory_section() +Description of problem: +It seems the frame buffer is not properly initialized before usage. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine smdkc210 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0x11c00020 0x3454d403 +writel 0x11c00000 0x61988eaf +EOF +``` +Additional information: +``` +==13250==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5590b12d2240). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3376651198 +INFO: Loaded 1 modules (583356 inline 8-bit counters): 583356 [0x5590b4672000, 0x5590b47006bc), +INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x5590b3d8b3b0,0x5590b4671f70), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: 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 , *exynos4210.fimd* +This process will fuzz the following MemoryRegions: + * exynos4210.fimd[0] (size 4114) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * exynos4210.fimd, EVENT_TYPE_MMIO_READ, 0x11c00000 +0x4114, 4,4 + * exynos4210.fimd, EVENT_TYPE_MMIO_WRITE, 0x11c00000 +0x4114, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 227Mb +Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd-crash-eda3de9b6941dd8c14e22959b56dbe5d8d07dae3 +qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: ../hw/display/exynos4210_fimd.c:1152: void fimd_update_memory_section(Exynos4210fimdState *, unsigned int): Assertion `w->mem_section.mr' failed. +==13250== ERROR: libFuzzer: deadly signal + #0 0x5590acce30ee in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x5590acc31d61 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5590acc0ac96 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x5590acc0ad62 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x5590acc0ad62 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f9ed33c741f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f9ed31d900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f9ed31d900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f9ed31b8858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f9ed31b8728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f9ed31c9fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x5590ad56dce3 in fimd_update_memory_section /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1152:5 + #12 0x5590ad565fb7 in exynos4210_fimd_enable /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1198:13 + #13 0x5590ad5590a3 in exynos4210_fimd_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1387:13 + #14 0x5590b03e7bc3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #15 0x5590b03e7501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #16 0x5590b03e5e26 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #17 0x5590b047669e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #18 0x5590b046444b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #19 0x5590b0463f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #20 0x5590acd23d38 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #21 0x5590acd220a3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #22 0x5590b12cd6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #23 0x5590b12c4a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #24 0x5590b12c47e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #25 0x5590acd2b07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #26 0x5590b12d250b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #27 0x5590acc0b806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x5590acbee434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x5590acbf93de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x5590acbe59c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7f9ed31ba082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x5590acbe5a1d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd+0x31cea1d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/gemma3:12b/device/1409 b/results/classifier/gemma3:12b/device/1409 new file mode 100644 index 000000000..ce7cbbfca --- /dev/null +++ b/results/classifier/gemma3:12b/device/1409 @@ -0,0 +1,2 @@ + +make check failed about qemu@7.2.0on suse15_aarch64 diff --git a/results/classifier/gemma3:12b/device/1418 b/results/classifier/gemma3:12b/device/1418 new file mode 100644 index 000000000..a009f50d6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1418 @@ -0,0 +1,88 @@ + +Underflow in xlnx_dp_aux_pop_tx_fifo() +Description of problem: +Pop from s->tx_fifo but s->tx_fifo has zero element. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xfd4a0100 0x19c4406f +EOF +``` +Additional information: +``` ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./crash-c15714102f0b894dea5c22f38852311567380926.minimized +==14660==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55db5cf9b840). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1977030529 +INFO: Loaded 1 modules (618603 inline 8-bit counters): 618603 [0x55db600fa000, 0x55db6019106b), +INFO: Loaded 1 PC tables (618603 PCs): 618603 [0x55db5f788d60,0x55db600f9410), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: 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 , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio* +This process will fuzz the following MemoryRegions: + * xlnx.v-dp.core[0] (size 3b0) + * xlnx.v-dp.v_blend[0] (size 1e0) + * xlnx.v-dp.audio[0] (size 50) + * xlnx.v-dp.av_buffer_manager[0] (size 238) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 488Mb +Running: ./crash-c15714102f0b894dea5c22f38852311567380926.minimized +aarch64: xlnx_dp_aux_pop_tx_fifo: TX_FIFO underflow +==14660== ERROR: libFuzzer: deadly signal + #0 0x55db5837410e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55db582c2d81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55db5829bcb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55db5829bd82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55db5829bd82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f98a612541f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f98a5f3700a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f98a5f3700a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f98a5f16858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x55db583a465a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x55db58cce4d8 in xlnx_dp_aux_pop_tx_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:476:9 + #11 0x55db58cc9ee7 in xlnx_dp_aux_set_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:524:22 + #12 0x55db58cc6a92 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:800:9 + #13 0x55db5bf4eec3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #14 0x55db5bf4e801 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #15 0x55db5bf4d126 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #16 0x55db5bfdb2de in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #17 0x55db5bfc941b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #18 0x55db5bfc8ed8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #19 0x55db583b40cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5 + #20 0x55db583b2544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28 + #21 0x55db5cf971ff in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #22 0x55db5cf8e57b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #23 0x55db5cf8e450 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #24 0x55db583bb10c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #25 0x55db5cf9bae2 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #26 0x55db5829c826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #27 0x55db5827f454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #28 0x55db5828a3fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #29 0x55db582769e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #30 0x7f98a5f18082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #31 0x55db58276a3d in _start (/root/bugs/metadata/xlnx_dp-06/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x6f,0x40,0xc4,0x19,0x0,0x0,0x0,0x0, +\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00o@\xc4\x19\x00\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/device/1419 b/results/classifier/gemma3:12b/device/1419 new file mode 100644 index 000000000..fe0488df0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1419 @@ -0,0 +1,93 @@ + +Overflow in xlnx_dp_aux_push_rx_fifo() +Description of problem: +Pushing stuff into s->rx_fifo many times make s->rx_fifo overflow. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xfd4a0100 0x7fb141e6 +writel 0xfd4a0100 0x7fb141e6 +writel 0xfd4a0100 0x7fb141e6 +EOF +``` +Additional information: +``` +root@3728b1f90dbd:~/bugs/metadata/xlnx_dp-03# bash -x xlnx_dp-03.videzzo ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-a6a2bd23ff0408dd50652670fdcdf9f5ceaab95d.minimized +==767==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55d36d8b3870). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1781001818 +INFO: Loaded 1 modules (618604 inline 8-bit counters): 618604 [0x55d370a12000, 0x55d370aa906c), +INFO: Loaded 1 PC tables (618604 PCs): 618604 [0x55d3700a0ce0,0x55d370a113a0), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: 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 , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio* +This process will fuzz the following MemoryRegions: + * xlnx.v-dp.core[0] (size 3b0) + * xlnx.v-dp.v_blend[0] (size 1e0) + * xlnx.v-dp.audio[0] (size 50) + * xlnx.v-dp.av_buffer_manager[0] (size 238) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 492Mb +Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-a6a2bd23ff0408dd50652670fdcdf9f5ceaab95d.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed. +==767== ERROR: libFuzzer: deadly signal + #0 0x55d368c8c10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55d368bdad81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55d368bb3cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55d368bb3d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55d368bb3d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f9897d8741f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f9897b9900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f9897b9900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f9897b78858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f9897b78728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f9897b89fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55d36d56bff3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:43:5 + #12 0x55d3695e64d3 in xlnx_dp_aux_push_rx_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:436:5 + #13 0x55d3695e1e9a in xlnx_dp_aux_set_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:513:13 + #14 0x55d3695dea92 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:805:9 + #15 0x55d36c866ef3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #16 0x55d36c866831 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #17 0x55d36c865156 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #18 0x55d36c8f330e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #19 0x55d36c8e144b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #20 0x55d36c8e0f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #21 0x55d368ccc0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5 + #22 0x55d368cca544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28 + #23 0x55d36d8af22f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #24 0x55d36d8a65ab in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #25 0x55d36d8a6480 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #26 0x55d368cd310c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #27 0x55d36d8b3b12 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #28 0x55d368bb4826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #29 0x55d368b97454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #30 0x55d368ba23fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #31 0x55d368b8e9e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #32 0x7f9897b7a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #33 0x55d368b8ea3d in _start (/root/bugs/metadata/xlnx_dp-03/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0, +\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/device/1423528 b/results/classifier/gemma3:12b/device/1423528 new file mode 100644 index 000000000..96edccc44 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1423528 @@ -0,0 +1,20 @@ + + setting unsupported timeout for i6300esb watchdog causes hw reset + +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778291 +Version: 2.1 + +systemd utilizes existing watchdog hardware and set's a 10min timer on reboot. +The i6300esb under qemu doesn't like such a timeout, and immediately resets the hardware: + +The last message one gets is +[ 9.402243] i6300esb: Unexpected close, not stopping watchdog! + + +The linked bug report contains information how this bug can easily be reproduced. +With any image using a recent enough systemd as PID 1 you should be able to reproduce it by running + +qemu-system-x86_64 -curses -enable-kvm -device i6300esb -watchdog-action reset -hda <image with systemd> + + +I'm uncertain if this is a qemu or kernel/driver bug. If the latter, please re-assign the bug as necessary. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1424 b/results/classifier/gemma3:12b/device/1424 new file mode 100644 index 000000000..888e55c00 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1424 @@ -0,0 +1,104 @@ + +Overflow in xlnx_dp_aux_push_tx_fifo() +Description of problem: +Invoking xlnx_dp_aux_push_tx_fifo() 17 times overflow the s->tx_fifo. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x666e0fa2 +writel 0xfd4a0104 0x666e0fa2 +writel 0xfd4a0104 0x666e0fa2 +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +EOF +``` +Additional information: +``` +root@621cbd136b6f:~/bugs/metadata/xlnx_dp-07# bash -x xlnx_dp-07.videzzo ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized +==47609==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x564c9e37c2b0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 2128347645 +INFO: Loaded 1 modules (600768 inline 8-bit counters): 600768 [0x564ca198f000, 0x564ca1a21ac0), +INFO: Loaded 1 PC tables (600768 PCs): 600768 [0x564ca1063b10,0x564ca198e710), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: 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 , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio* +This process will fuzz the following MemoryRegions: + * xlnx.v-dp.core[0] (size 3b0) + * xlnx.v-dp.v_blend[0] (size 1e0) + * xlnx.v-dp.audio[0] (size 50) + * xlnx.v-dp.av_buffer_manager[0] (size 238) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 510Mb +Running: ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed. +==47609== ERROR: libFuzzer: deadly signal + #0 0x564c998420fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x564c99790d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x564c99769ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x564c99769d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x564c99769d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f8ef929941f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f8ef90ab00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f8ef90ab00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f8ef908a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f8ef908a728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f8ef909bfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x564c9e1cdbb3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:43:5 + #12 0x564c9a189c13 in xlnx_dp_aux_push_tx_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:467:5 + #13 0x564c9a1842f2 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:857:9 + #14 0x564c9d491e93 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #15 0x564c9d4917d1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #16 0x564c9d4900f6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #17 0x564c9d5209ce in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #18 0x564c9d50e77b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #19 0x564c9d50e238 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #20 0x564c99882d48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #21 0x564c998810b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #22 0x564c9e37772f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #23 0x564c9e36eaad in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #24 0x564c9e36e854 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #25 0x564c9988a08c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #26 0x564c9e37c57b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #27 0x564c9976a816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x564c9974d444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x564c997583ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x564c997449d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7f8ef908c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x564c99744a2d in _start (/root/bugs/metadata/xlnx_dp-07/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3453a2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/gemma3:12b/device/1427 b/results/classifier/gemma3:12b/device/1427 new file mode 100644 index 000000000..e4e996337 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1427 @@ -0,0 +1,375 @@ + +Fifo overflow in transfer_fifo() +Description of problem: +In transfer_fifo(), fifo32_push() fails since less than 32 bytes are free in the +fifo. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x554439e4 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x7439dad1 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x554439e4 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x7439dad1 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070030 0x5b33c2da +writel 0xff070004 0x6847773b +writel 0xff070030 0x5b33c2da +writel 0xff070000 0x7a9e77fa +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x0bbac0b1 +readl 0xff070054 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +EOF +``` +Additional information: +``` +==60953==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55c4943a85f0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1771329340 +INFO: Loaded 1 modules (600781 inline 8-bit counters): 600781 [0x55c4979bb000, 0x55c497a4dacd), +INFO: Loaded 1 PC tables (600781 PCs): 600781 [0x55c49708fbf0,0x55c4979ba8c0), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: 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 , *xlnx.zynqmp-can* +This process will fuzz the following MemoryRegions: + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 509Mb +Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-8c83f08fb7643e6eb55af43e76de522c6f5fcef2.minimized.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:34: void fifo8_push(Fifo8 *, uint8_t): Assertion `fifo->num < fifo->capacity' failed. +==60953== ERROR: libFuzzer: deadly signal + #0 0x55c48f86e0fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55c48f7bcd71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55c48f795ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55c48f795d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55c48f795d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7fe36599541f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fe3657a700a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fe3657a700a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fe365786858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7fe365786728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7fe365797fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55c4941f98ef in fifo8_push /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:34:5 + #12 0x55c490d83bb0 in fifo32_push /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:94:9 + #13 0x55c490d79d17 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/net/can/xlnx-zynqmp-can.c:476:21 + #14 0x55c490d71a00 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/net/can/xlnx-zynqmp-can.c:836:9 + #15 0x55c48fdfaf9b in register_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/core/register.c:122:9 + #16 0x55c48fdfefb8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/out-san/../hw/core/register.c:203:5 + #17 0x55c4934be1d3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #18 0x55c4934bdb11 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #19 0x55c4934bc436 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #20 0x55c49354cd0e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #21 0x55c49353aabb in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #22 0x55c49353a578 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #23 0x55c48f8aed48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #24 0x55c48f8ad0b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #25 0x55c4943a3a6f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #26 0x55c49439aded in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #27 0x55c49439ab94 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #28 0x55c48f8b608c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #29 0x55c4943a88bb in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #30 0x55c48f796816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #31 0x55c48f779444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #32 0x55c48f7843ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #33 0x55c48f7709d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #34 0x7fe365788082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #35 0x55c48f770a2d in _start (/root/bugs/metadata/xlnx_zynqmp_can-01/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3454a2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/gemma3:12b/device/1429 b/results/classifier/gemma3:12b/device/1429 new file mode 100644 index 000000000..78f8a9d6d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1429 @@ -0,0 +1,56 @@ + +Out of bounds in xilinx_spips_write() +Description of problem: +The size of TYPE_XILINX_SPIPS's and TYPE_XILINX_QSPIPS's memory regions is +0x100, but it is set to 0x200. UBSAN captures Out of bounds accesses. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 +export UBSAN_OPTIONS=halt_on_error=1:symbolize=1:print_stacktrace=1 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writew 0xff050108 0x29be +EOF +``` +Additional information: +``` +==852678==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000001] OPENED +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument +qemu-system-aarch64: warning: nic cadence_gem.0 has no peer +qemu-system-aarch64: warning: nic cadence_gem.1 has no peer +qemu-system-aarch64: warning: nic cadence_gem.2 has no peer +qemu-system-aarch64: warning: nic cadence_gem.3 has no peer +[R +0.323364] writew 0xff050108 0x29be +../hw/ssi/xilinx_spips.c:1031:22: runtime error: index 66 out of bounds for type 'uint32_t [64]' + #0 0x55b7450b6895 in xilinx_spips_write /home/liuqiang/project-videzzo/qemu-devel/build/../hw/ssi/xilinx_spips.c:1031:22 + #1 0x55b747b29790 in memory_region_write_accessor /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:493:5 + #2 0x55b747b28c2d in access_with_adjusted_size /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:555:18 + #3 0x55b747b268f4 in memory_region_dispatch_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:1515:16 + #4 0x55b747c1a071 in flatview_write_continue /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2825:23 + #5 0x55b747c00d92 in flatview_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2867:12 + #6 0x55b747c007b8 in address_space_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2963:18 + #7 0x55b747c49f31 in qtest_process_command /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:528:13 + #8 0x55b747c42f6e in qtest_process_inbuf /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:802:9 + #9 0x55b747c5b783 in qtest_read /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:814:5 + #10 0x55b748c6b602 in qemu_chr_be_write_impl /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char.c:201:9 + #11 0x55b748c6b74a in qemu_chr_be_write /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char.c:213:9 + #12 0x55b748c81f6a in fd_chr_read /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char-fd.c:72:9 + #13 0x55b7481cbe66 in qio_channel_fd_source_dispatch /home/liuqiang/project-videzzo/qemu-devel/build/../io/channel-watch.c:84:12 + #14 0x7fbad3de404d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) + #15 0x55b74923a917 in glib_pollfds_poll /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:297:9 + #16 0x55b749238017 in os_host_main_loop_wait /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:320:5 + #17 0x55b749237967 in main_loop_wait /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:606:11 + #18 0x55b745858753 in qemu_main_loop /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/runstate.c:739:9 + #19 0x55b74304cf34 in qemu_default_main /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/main.c:37:14 + #20 0x55b74304cfd0 in main /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/main.c:48:12 + #21 0x7fbad227a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #22 0x55b742fa271d in _start (/home/liuqiang/project-videzzo/qemu-devel/build/qemu-system-aarch64+0x3dc371d) + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ssi/xilinx_spips.c:1031:22 in +``` diff --git a/results/classifier/gemma3:12b/device/143 b/results/classifier/gemma3:12b/device/143 new file mode 100644 index 000000000..630104961 --- /dev/null +++ b/results/classifier/gemma3:12b/device/143 @@ -0,0 +1,2 @@ + +xhci HCIVERSION register read emulation incorrectly handled diff --git a/results/classifier/gemma3:12b/device/1436 b/results/classifier/gemma3:12b/device/1436 new file mode 100644 index 000000000..484103264 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1436 @@ -0,0 +1,62 @@ + +Out of memory in hw/omap-dss for ARM +Description of problem: +In omap-dss, g_realloc() can allocate a large buffer using out of the memory. + +- [1] set pixels to any value +- [2] double pixels +- [3] allocate a large buffer + +``` +static void omap_rfbi_write(...) { + switch (addr) { + case 0x44: /* RFBI_PIXELCNT */ + s->rfbi.pixels = value; // ------------------------------------> [1] + break; + +static void omap_rfbi_transfer_start(struct omap_dss_s *s) { + len = s->rfbi.pixels * 2; // -------------------------------------> [2] + if (!data) { + if (len > bounce_len) { + bounce_buffer = g_realloc(bounce_buffer, len); // ---------> [3] + } +``` +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine n810,accel=qtest -m 128M -qtest stdio -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0x48050440 0x74a57907 +writel 0x48050858 0x34982d63 +writel 0x48050840 0x65a61a51 +EOF +``` +Additional information: +``` + +================================================================= +==1029323==ERROR: AddressSanitizer: requested allocation size 0xfffffffffffffffe (0x800 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0) + #0 0x7f4650b4ec3e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163 + #1 0x7f464fa27f3f in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57f3f) + #2 0x55cf6212c85b in omap_rfbi_write ../hw/display/omap_dss.c:761 + #3 0x55cf636b9c9b in memory_region_write_accessor ../softmmu/memory.c:493 + #4 0x55cf636ba132 in access_with_adjusted_size ../softmmu/memory.c:555 + #5 0x55cf636c76f8 in memory_region_dispatch_write ../softmmu/memory.c:1515 + #6 0x55cf637049b9 in flatview_write_continue ../softmmu/physmem.c:2825 + #7 0x55cf63704ddc in flatview_write ../softmmu/physmem.c:2867 + #8 0x55cf637057c4 in address_space_write ../softmmu/physmem.c:2963 + #9 0x55cf63716261 in qtest_process_command ../softmmu/qtest.c:533 + #10 0x55cf6371ac52 in qtest_process_inbuf ../softmmu/qtest.c:802 + #11 0x55cf6371ad43 in qtest_read ../softmmu/qtest.c:814 + #12 0x55cf63d4d5e5 in qemu_chr_be_write_impl ../chardev/char.c:201 + #13 0x55cf63d4d68c in qemu_chr_be_write ../chardev/char.c:213 + #14 0x55cf63d544c9 in fd_chr_read ../chardev/char-fd.c:72 + #15 0x55cf63938b9b in qio_channel_fd_source_dispatch ../io/channel-watch.c:84 + #16 0x7f464fa2204d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) + +==1029323==HINT: if you don't care about these errors you may set allocator_may_return_null=1 +SUMMARY: AddressSanitizer: allocation-size-too-big ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163 in __interceptor_realloc +==1029323==ABORTING +``` diff --git a/results/classifier/gemma3:12b/device/1437367 b/results/classifier/gemma3:12b/device/1437367 new file mode 100644 index 000000000..fe9d8dc5e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1437367 @@ -0,0 +1,25 @@ + +Qemu guest fails to write files with raw disk (like \\.\PhysicalDrive1) on Windows host. + +Qemu guest fails to write files with specifing raw disk like \\.\PhysicalDrive1 +full command line is below. +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi + +I found the reason is below aio_worker returns -EIO when flush operation. + +https://github.com/qemu/qemu/blob/master/block/raw-win32.c#L95 + +static int aio_worker(void *arg) +... + case QEMU_AIO_FLUSH: + if (!FlushFileBuffers(aiocb->hfile)) { + return -EIO; + } + +FlushFileBuffers always fails with GetLastError() == ERROR_INVALID_FUNCTION +I think this function doesn't support raw device. +For flushing, you might have to issue scsi/ata command or use another way. +Trying to just ignoring this error, writing function seems to be fine for me. + +Thanks +hiroaki \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1440843 b/results/classifier/gemma3:12b/device/1440843 new file mode 100644 index 000000000..17b3eba21 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1440843 @@ -0,0 +1,15 @@ + +Guest WinXP crashes when trying to use a USB spectrometer + +I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: + +1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" +2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" +3. command line parameter "-usbdevice host:2457:1030 +4. command line parameter "-usbdevice host:3.25" +5. qemu console command "usb_add host:2457:1030" +5. qemu console command "usb_add host:3.25" + +From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. + +I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1445 b/results/classifier/gemma3:12b/device/1445 new file mode 100644 index 000000000..1c4e25c4a --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1445633 b/results/classifier/gemma3:12b/device/1445633 new file mode 100644 index 000000000..7a24462f6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1446 b/results/classifier/gemma3:12b/device/1446 new file mode 100644 index 000000000..727a1fb1e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1446 @@ -0,0 +1,176 @@ + +Heap buffer overflow in nand_blk_write_512() +Description of problem: +I captured the negative-size-param (memcpy) in nand_blk_load_512() like below. + +``` +diff --git a/hw/block/nand.c b/hw/block/nand.c +index 8bc80e351..f68b23d05 100644 +--- a/hw/block/nand.c ++++ b/hw/block/nand.c +@@ -790,6 +790,10 @@ static void glue(nand_blk_load_, NAND_PAGE_SIZE)(NANDFlashState *s, + s->ioaddr = s->io + (PAGE_START(addr) & 0x1ff) + offset; + } + } else { ++ int size = NAND_PAGE_SIZE + OOB_SIZE - offset; ++ if (size < 0) { ++ return; ++ } + memcpy(s->io, s->storage + PAGE_START(s->addr) + + offset, NAND_PAGE_SIZE + OOB_SIZE - offset); + s->ioaddr = s->io; + +``` + +Then, I triggered an integer overflow in nand_blk_write_512() resulting in a +heap buffer overflow. Specifically, s->iolen is a signed integer[1], but based +on the function signature of mem_and(), s->iolen will be casted to an unsigned +integer[2]. Asan then captures a heap buffer overflow[3]. + +``` +static void glue(nand_blk_write_, NAND_PAGE_SIZE)(NANDFlashState *s) +{ + // ... + if (!s->blk) { + mem_and(s->storage + PAGE_START(s->addr) + (s->addr & PAGE_MASK) + + s->offset, s->io, s->iolen); // <--------------- [1] + } else if (s->mem_oob) { + // ... + +static void mem_and(uint8_t *dest, const uint8_t *src, size_t n) // <--- [2] +{ + int i; + for (i = 0; i < n; i++) { + dest[i] &= src[i]; // <----------------------------------------- [3] + } +} +``` +Steps to reproduce: +Please patch your hw/block/nand.c first. + +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine tosa -monitor none -serial none \ +-display none -qtest stdio +write 0x10000111 0x1 0xca +write 0x10000104 0x1 0x47 +write 0x1000ca04 0x1 0xd7 +write 0x1000ca01 0x1 0xe0 +write 0x1000ca04 0x1 0x71 +write 0x1000ca00 0x1 0x50 +write 0x1000ca04 0x1 0xd7 +read 0x1000ca02 0x1 +write 0x1000ca01 0x1 0x10 +EOF +``` +Additional information: +``` +==15750==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x560e65814d70). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 4218744906 +INFO: Loaded 1 modules (601336 inline 8-bit counters): 601336 [0x560e68702000, 0x560e68794cf8), +INFO: Loaded 1 PC tables (601336 PCs): 601336 [0x560e67dd42a0,0x560e68701220), +/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: 281Mb +Running: /root/videzzo/videzzo_qemu/out-san/poc-qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb-crash-35f3f537422c4e74ce65177b3d6369045e60b47f.minimized +================================================================= +==15750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000000de0 at pc 0x560e61557210 bp 0x7ffcfc4a59f0 sp 0x7ffcfc4a59e8 +READ of size 1 at 0x61f000000de0 thread T0 + #0 0x560e6155720f in mem_and /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:101:20 + #1 0x560e6155ac9c in nand_blk_write_512 /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:663:9 + #2 0x560e61544200 in nand_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:293:13 + #3 0x560e6153cc83 in nand_setio /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:520:13 + #4 0x560e61a0a69e in tc6393xb_nand_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:380:13 + #5 0x560e619f9bf7 in tc6393xb_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:524:9 + #6 0x560e647c7d03 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #7 0x560e647c7641 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #8 0x560e647c5f66 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #9 0x560e6485409e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #10 0x560e648421eb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #11 0x560e64841ca8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #12 0x560e61170162 in qemu_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1080:5 + #13 0x560e6116eef7 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1227:28 + #14 0x560e6581072f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #15 0x560e65807aab in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #16 0x560e65807980 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #17 0x560e611780fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #18 0x560e65815012 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #19 0x560e61059816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #20 0x560e6103c444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #21 0x560e610473ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #22 0x560e610339d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #23 0x7f79587d0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #24 0x560e61033a2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb+0x300fa2d) + +0x61f000000de0 is located 0 bytes to the right of 3424-byte region [0x61f000000080,0x61f000000de0) +allocated by thread T0 here: + #0 0x560e611276cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 + #1 0x7f7959a87e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + #2 0x560e64b98871 in object_new /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:749:12 + #3 0x560e64b5d1a1 in qdev_new /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:153:19 + #4 0x560e61547ea5 in nand_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:639:11 + #5 0x560e619f8772 in tc6393xb_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:558:16 + #6 0x560e6390bad2 in tosa_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/arm/tosa.c:250:12 + #7 0x560e61730887 in machine_run_board_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/machine.c:1400:5 + #8 0x560e633bdd5b in qemu_init_board /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2485:5 + #9 0x560e633bda6c in qmp_x_exit_preconfig /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2581:5 + #10 0x560e633c4fef in qemu_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:3584:9 + #11 0x560e611763f3 in LLVMFuzzerInitialize /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1761:5 + #12 0x560e61043fab in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:664:29 + #13 0x560e610339d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #14 0x7f79587d0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:101:20 in mem_and +Shadow bytes around the buggy address: + 0x0c3e7fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff8170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff8180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c3e7fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa + 0x0c3e7fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff81d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff81f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff8200: 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 +==15750==ABORTING +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0xb,0x12,0x1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xca,0x4f,0x4d,0x5f,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0x1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x47,0xf0,0xc8,0x58,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0xa1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xd7,0x38,0xfc,0x29,0x0,0x0,0x0,0x0,0x1,0xb,0x1,0x9a,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xe0,0xb0,0x63,0x62,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0x8a,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x71,0xaa,0x20,0x60,0x0,0x0,0x0,0x0,0x1,0xb,0x0,0x5,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x50,0x9f,0x0,0x40,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0xa1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xd7,0x38,0xfc,0x29,0x0,0x0,0x0,0x0,0x0,0xa,0x2,0x24,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0xb,0x1,0xc5,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x10,0x8b,0x36,0x70,0x0,0x0,0x0,0x0, +\x01\x0b\x12\x01\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xcaOM_\x00\x00\x00\x00\x01\x0b\x04\x01\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00G\xf0\xc8X\x00\x00\x00\x00\x01\x0b\x04\xa1\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xd78\xfc)\x00\x00\x00\x00\x01\x0b\x01\x9a\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xe0\xb0cb\x00\x00\x00\x00\x01\x0b\x04\x8a\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00q\xaa `\x00\x00\x00\x00\x01\x0b\x00\x05\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00P\x9f\x00@\x00\x00\x00\x00\x01\x0b\x04\xa1\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xd78\xfc)\x00\x00\x00\x00\x00\x0a\x02$\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x01\x0b\x01\xc5\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x10\x8b6p\x00\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/device/1449 b/results/classifier/gemma3:12b/device/1449 new file mode 100644 index 000000000..d3f41848a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1449 @@ -0,0 +1,6 @@ + +RISCV: wrong check for vector extension ELEN value. +Description of problem: +When checking if the vector extension ELEN value is in the range [8, 64], the lower bound check uses the `vlen` field instead of the `elen` one: https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c#L885. +Additional information: +This is basically just a typo I found while reading the code, I do not have a real case scenario which resulted in this check to fail. diff --git a/results/classifier/gemma3:12b/device/1452742 b/results/classifier/gemma3:12b/device/1452742 new file mode 100644 index 000000000..7e46c520b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1453613 b/results/classifier/gemma3:12b/device/1453613 new file mode 100644 index 000000000..527a81ace --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1457 b/results/classifier/gemma3:12b/device/1457 new file mode 100644 index 000000000..19cbbd917 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1457 @@ -0,0 +1,2 @@ + +ide: assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. diff --git a/results/classifier/gemma3:12b/device/1458 b/results/classifier/gemma3:12b/device/1458 new file mode 100644 index 000000000..899edb3ba --- /dev/null +++ b/results/classifier/gemma3:12b/device/1458 @@ -0,0 +1,28 @@ + +ns16550a reg-shift incorrect for qemu-system-riscv64 +Description of problem: +Missing reg-shift 0 on the ns16550n in qemu-system-riscv64 creates an impossible assumption case. +Steps to reproduce: +1. qemu-system-riscv64 -M virt,dumpdtb=dtb +2. dtc dtb | less + + serial@10000000 { + interrupts = <0x0a>; + interrupt-parent = <0x03>; + clock-frequency = "\08@"; + reg = <0x00 0x10000000 0x00 0x100>; + compatible = "ns16550a"; + }; + +Generally, ns16550a has a default reg-shift of 0 on x86,x86_64 for compatibility reasons. All other architectures have an assumed reg-shift of 2 (or having the reg-shift assumption overridden by fdt providing a reg-shift property) + +Beyond the above, anything non-standard is assumed to be specified by the "reg-shift" property fdt. + +qemu-system-riscv64 seems to "assume" a reg-shift of 0. Other riscv64 devices don't supply "reg-shift" (SiFive Unmatched) and "assume" 2. +The above means driver writers don't actually know what to "assume" on riscv64 ns16550a when no reg-shift is present. + + +Essentially, qemu-system-riscv64 needs to do one of the following: + +* If serial ns16550a with a uart reg-shift of 0 is intentional, qemu needs to advertise the deviance via "reg-shift 0" +* If serial ns16550a with a uart reg-shift of 0 is unintentional, it needs updated to 2 so drivers can assume 2 on riscv64. diff --git a/results/classifier/gemma3:12b/device/1459 b/results/classifier/gemma3:12b/device/1459 new file mode 100644 index 000000000..092eaef1f --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1459626 b/results/classifier/gemma3:12b/device/1459626 new file mode 100644 index 000000000..ed710fd05 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1459626 @@ -0,0 +1,14 @@ + +emacs (gtk3) core dumped with -vga qxl + +Emacs (gtk3) exited with bus error and core dumped with -vga qxl. If I use the builtin modesetting xorg driver, emacs could survive for a short while sometimes. If I use xf86-video-qxl (git r587.8babd05), it dies right away with the same error. It seems to corrupt xorg at some point as well, because sometimes I cannot exit i3 properly and gnome-terminal can go crazy afterwards (all letters become empty retangles). + +It doesn't seem to happen with other -vga driver. + +Error message is attached. Can also provide the core dumped but it's of 47M. + +I started the vm as root (sudo) with the following command: qemu-system-x86_64 -enable-kvm -m 4G -virtfs local,mount_tag=qemu,security_model=passthrough,path=/mnt/qemu/ -kernel /mnt/qemu/boot/vmlinuz-linux -initrd /mnt/qemu/boot/initramfs-linux-fallback.img -append 'rw root=qemu fstype=9p' -usbdevice tablet -vga qxl -spice port=12345,disable-ticketing + +/mnt/qemu is a btrfs snapshot of the subvolume used as the host root + +Arch Linux, qemu 2.3.0, xorg-server 1.17.1, linux 4.0.4, gtk 3.16.3, glib 2.44.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/146 b/results/classifier/gemma3:12b/device/146 new file mode 100644 index 000000000..822fd275d --- /dev/null +++ b/results/classifier/gemma3:12b/device/146 @@ -0,0 +1,2 @@ + +macOS Guest Reading USB 3.0 Bus as USB 2.0 diff --git a/results/classifier/gemma3:12b/device/1460 b/results/classifier/gemma3:12b/device/1460 new file mode 100644 index 000000000..dcf6aea3f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1460 @@ -0,0 +1,6 @@ + +block_load fails if last block is included in snapshot and block device isn't multiple of BLK_MIG_BLOCK_SIZE +Description of problem: +The `block_load` function in `migration/block.c` has a bug where `blk_pwrite` or `blk_pwrite_zeroes` always write `cluster_size` bytes. If the underlying device is not a multiple of `BLK_MIG_BLOCK_SIZE`, the write will fail with -EIO when trying to write past the end of the device, as `blk_check_byte_request` checks the length of the device. + +This can be fixed by ensuring that `cur_addr` + write length passed to `blk_pwrite`/`blk_pwrite_zeroes` never exceeds the total length of the block device. diff --git a/results/classifier/gemma3:12b/device/1463 b/results/classifier/gemma3:12b/device/1463 new file mode 100644 index 000000000..798627bab --- /dev/null +++ b/results/classifier/gemma3:12b/device/1463 @@ -0,0 +1,42 @@ + +VM with ivshmem and host pci device does not boot +Description of problem: +The boot aborts early if ivshmem and host-pci devices are used at the same time. +Steps to reproduce: +1. use a recent host kernel => 6.1.8 +2. use qemu from bullseye-backports (7.2) +3. use a recent edk2 bios with 4M secure boot + SMM +4. add ivshmem with e.g.: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +5. add a host-pci device to the VM +6. try to boot he VM +Additional information: +Observations: +always add ivshmem with: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +- a) no host-pci device + edk2 with secure boot => works +- b) with host-pci device + non edk2 => works +- c) with host-pci device + edk2 with secure boot => does not work +- d) with host-pci device + edk2 with secure boot + but without ivshmem => works + + +I have compiled a debug version of qemu und added some prints to the linux kernel. + +Qemu log shows: +``` +2023-01-25T23:30:47.128716Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument +2023-01-25T23:30:47.128741Z qemu-system-x86_64: vfio_dma_map(0x55cee4bf7b20, 0x385000000000, 0x2000000, 0x7fd7253ff000) = -2 (No such file or directory) +qemu: hardware error: vfio: DMA mapping failed, unable to continue +``` + +Kernel log prints in vfio_iommu_iova_dma_valid@drivers/vfio/vfio_iommu_type1.c - if (start >= node->start && end <= node->end): +``` +[ 1156.241294] DEBUG valid 1048576 >= 0 && 2147483647 <= 4276092927 +[ 1156.269472] DEBUG valid 1048576 >= 0 && 2130706431 <= 4276092927 +[ 1156.477577] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.478889] DEBUG valid 3254779904 >= 0 && 3254845439 <= 4276092927 +[ 1156.481226] DEBUG valid 3254779904 >= 0 && 3255042047 <= 4276092927 +[ 1156.482864] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.502867] DEBUG valid 61916248539136 >= 0 && 61916282093567 <= 4276092927 +[ 1156.502870] DEBUG valid 61916248539136 >= 4277141504 && 61916282093567 <= 549755813887 +``` + +The vfio_dma_map ioctl request from qemu to the kernel seems to fail because 0x385000000000 from qemu is not in any iova range known by the kernel. diff --git a/results/classifier/gemma3:12b/device/1464611 b/results/classifier/gemma3:12b/device/1464611 new file mode 100644 index 000000000..c046f4bff --- /dev/null +++ b/results/classifier/gemma3:12b/device/1464611 @@ -0,0 +1,30 @@ + +4 * redundant conditions + + +1. + +[qemu/hw/block/nvme.c:355]: (style) Redundant condition: sqid. 'A && (!A || B)' is equivalent to 'A || B' + + if (!sqid || (sqid && !nvme_check_sqid(n, sqid))) { + +2. + +[qemu/hw/block/nvme.c:429]: (style) Redundant condition: cqid. 'A && (!A || B)' is equivalent to 'A || B' + + if (!cqid || (cqid && !nvme_check_cqid(n, cqid))) { + +3. + +[qemu/hw/tpm/tpm_passthrough.c:157]: (style) Redundant condition: tpm_pt.tpm_op_canceled. 'A && (!A || B)' is equivalent to 'A || B' + + if (!tpm_pt->tpm_op_canceled || + (tpm_pt->tpm_op_canceled && errno != ECANCELED)) { + +4. + +[qemu/target-arm/translate-a64.c:5729]: (style) Redundant condition: size<3. 'A && (!A || B)' is equivalent to 'A || B' + + if (size > 3 + || (size < 3 && is_q) + || (size == 3 && !is_q)) { \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1465 b/results/classifier/gemma3:12b/device/1465 new file mode 100644 index 000000000..73617f41f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1465 @@ -0,0 +1,2 @@ + +MBR/Partition table corruption/loss , probably related to virtual sata disks and backup diff --git a/results/classifier/gemma3:12b/device/1470 b/results/classifier/gemma3:12b/device/1470 new file mode 100644 index 000000000..1fd8c6c87 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1470 @@ -0,0 +1,10 @@ + +Mouse cursor disappeared for WfW 3.11 +Description of problem: +I've been using the "GD5434 v1.25f, 1280x1024x64K Smlfnt" driver (from sp2904.exe, https://archive.org/download/Windows-3.1-WING-doom inside cirrus.zip) with Fedora's qemu build for years, which is the best version of that driver that I could find, and which works quite nicely apart from a font problem right after startup, and is a lot faster than the standard (patched) SVGA driver. Opening and closing File Manager will get rid of the font corruption. After an upgrade to Fedora 37, I noticed that the mouse cursor was not displayed anymore, which I bisected to this git commit: cb8962c146 +Steps to reproduce: +1. Run the image (boots right into Windows) +2. Note the missing cursor +3. +Additional information: +Image for easy testing (IBM DOS 5, 1024x768) is here: https://drive.google.com/file/d/1_5-gGXEahPOPvgG436WbKM9dnOr7Z8zo/view?usp=sharing (4.4 MB) diff --git a/results/classifier/gemma3:12b/device/1470536 b/results/classifier/gemma3:12b/device/1470536 new file mode 100644 index 000000000..26cd71c5f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1470536 @@ -0,0 +1,13 @@ + +qemu-img incorrectly prints "qemu-img: Host floppy pass-through is deprecated" + +qemu-img incorrectly prints this warning when you use /dev/fd/<NN> to pass in file descriptors. A simple way to demonstrate this uses bash process substitution, so the following will only work if you are using bash as your shell: + +$ qemu-img info <( cat /dev/null ) +qemu-img: Host floppy pass-through is deprecated +Support for it will be removed in a future release. +qemu-img: Could not open '/dev/fd/63': Could not refresh total sector count: Illegal seek + +The root cause is a bug in block/raw-posix.c:floppy_probe_device() where it thinks anything starting with /dev/fd is a floppy drive, which is not the case here: + +http://git.qemu.org/?p=qemu.git;a=blob;f=block/raw-posix.c;h=cbe6574bf4da90a124436a40422dce3667da71e6;hb=HEAD#l2425 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1471583 b/results/classifier/gemma3:12b/device/1471583 new file mode 100644 index 000000000..520bd3c31 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1471583 @@ -0,0 +1,69 @@ + +QCA988X Wifi Card Not PCI Passing Through + +CPU: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz +KVM: qemu-kvm-1.5.3-86.el7_1.2.x86_64 +Kernel: 4.1.1-1.el7.elrepo.x86_64, and kernel-3.10.0-229.7.2.el7.x86_64 +Host & Guest: CentOS 7.1 +Using virt-manager-1.1.0-12.el7.noarch to create, configure, and start guest + +I am trying to do a PCI passthrough of a QCA988X wifi card. It's a Doodle Labs military-grade 802.11ac miniPCI card, which uses the ath10k kernel driver. This card configures nicely on the host, and seems to pass through to the guest, but early in the boot of the guest it says "Unknown header type" at the wifi's bus address. And sure enough, lspci -vv on the host then shows: + !!! Unknown header type 7f + Kernel driver in use: vfio-pci + +When the guest has booted, of course it shows as an Unclassified device. Host and guest must run at least kernel 4.0 so the wifi card's current firmware will load, and so that its driver comes with the kernel. I have both host and guest set up for the wifi card. I tried running kernel 3.10 in the host and passing through the PCI device, but same behavior. + +I am passing through to the guest an Intel i350 ethernet card just fine, in fact I'm passing through two of its SR-IOV virt interfaces to the guest, so that works. + +On the host, before I start the guest, the wifi card looks like this (lspci -vv): + +0a:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter + 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- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 43 + Region 0: Memory at f7000000 (64-bit, non-prefetchable) [size=2M] + Expansion ROM at f7200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit- + Address: fee00618 Data: 0000 + Masking: 00000000 Pending: 00000000 + Capabilities: [70] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- + DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us + ClockPM- Surprise- LLActRep- BwNot- + 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- + DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled + LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- + EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- + 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, GenCap- CGenEn- ChkCap- ChkEn- + Capabilities: [140 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 + Status: NegoPending- InProgress- + Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 + Kernel driver in use: ath10k_pci \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1471904 b/results/classifier/gemma3:12b/device/1471904 new file mode 100644 index 000000000..83a8b5d63 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1471904 @@ -0,0 +1,65 @@ + +qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974 + +I try to do a fresh install of NeXTStep 3.3 on qemu. After all install floppies are successfully read in, the installation shall start, but aborts right away. During installation process the SCSI host adapter is correctly detected. I don't know, if these adapter where equipped with some special ROM. I thought of installing NeXTStep on a SCSI system due to the IDE problems already known under #1276879. If necessary I would use gdb to track more into this. + +System info: +Linux prerow 3.11.10-29-desktop #1 SMP PREEMPT Thu Mar 5 16:24:00 UTC 2015 (338c513) x86_64 x86_64 x86_64 GNU/Linux +NAME=openSUSE +VERSION="13.1 (Bottle)" +VERSION_ID="13.1" +PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" + +qemu commandline parameter: +/usr/bin/qemu-system-i386 \ + -cpu pentium \ + -monitor stdio \ + -k de \ + -vga cirrus \ + -m 128 \ + -localtime \ + -drive \ + file=.qemu/floppy/3.3_Boot_Disk.floppyimage,format=raw,if=floppy,index=0 \ + -drive \ + file=.qemu/disk/scsihd-2G.qcow2,format=qcow2,id=scsihd0,if=none \ + -drive \ + file=.qemu/cdrom/3.3_InstallCD-NeXTIntel.cdromimage,format=raw,id=scsicd0,if=none \ + -net \ + none \ + -device \ + am53c974,id=AMD0 \ + -device \ + scsi-cd,drive=scsicd0,bus=AMD0.0,lun=0,scsi-id=1,physical_block_size=512,logical_block_size=512 \ + -device \ + scsi-hd,drive=scsihd0,bus=AMD0.0,lun=0,scsi-id=0,removable=off,secs=125,heads=8,cyls=4176,product="ST32151N ",vendor="Seagate ",serial="89683587",ver="2356",physical_block_size=512,logical_block_size=512,dpofua=off + +qemu error message: +qemu: fatal: Trying to execute code outside RAM or ROM at 0xc01754a8 + +EAX=000000ff EBX=0000fffb ECX=000000ff EDX=000000a1 +ESI=00000009 EDI=00011010 EBP=0000ff84 ESP=0000ff6c +EIP=001754a8 EFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +CS =0008 c0000000 3fffffff 00c39a00 DPL=0 CS32 [-R-] +SS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +DS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +FS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +GS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 001c9a58 000000ff +IDT= 001c9bac 000007ff +CR0=00000033 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000001 CCD=0000000c CCO=INCL +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +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=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1472 b/results/classifier/gemma3:12b/device/1472 new file mode 100644 index 000000000..046aecdb7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1472 @@ -0,0 +1,6 @@ + +Parameter 'sgx-epc.0.node' is unexpected +Description of problem: +qemu-system-x86_64: Parameter 'sgx-epc.0.node' is unexpected +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1479 b/results/classifier/gemma3:12b/device/1479 new file mode 100644 index 000000000..07e5482e0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1479 @@ -0,0 +1,2 @@ + +system/arm/cpu-features.html : text describing options is misrendered diff --git a/results/classifier/gemma3:12b/device/1483 b/results/classifier/gemma3:12b/device/1483 new file mode 100644 index 000000000..33219fd25 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1483 @@ -0,0 +1,2 @@ + +Failed to mount pmem device in qemu diff --git a/results/classifier/gemma3:12b/device/1483070 b/results/classifier/gemma3:12b/device/1483070 new file mode 100644 index 000000000..4c723d3b0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1483070 @@ -0,0 +1,20 @@ + +VIRTIO Sequential Write IOPS limits not working + +Root Problem: +IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. + +To confirm: +IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. + +Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. + +For Linux: +The issue is also apparent, tested on Ubuntu 14.04 + +On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 and 4) using multiple machines but all are 64bit intel. + +Even though the latest VIRTIO guest drivers fix the problem, the guest drivers shouldn't be able to ignore the limits the host puts in place or am I missing something?? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1485 b/results/classifier/gemma3:12b/device/1485 new file mode 100644 index 000000000..677a6230d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1485 @@ -0,0 +1,13 @@ + +hw/at24c : not support 1 byte-address with eeprom size less than 256 byte +Description of problem: +I created the new platform base on aspeed/fuji, +that uses the virtual eeprom (at24c), some eeprom used 24c02, which size 256 bytes. +but when using /hw/at24c.c, the result will not same the real device. +Steps to reproduce: +1. create a machine with EEPROM size less then or equal 256 bytes +2. start the qemu +3. use i2cget/i2cset/i2cdump to write and display eeprom data +Additional information: +I fixed and validated, refer +https://gitlab.com/ssinprem/qemu/-/tree/at24c-1-byte-address-mode diff --git a/results/classifier/gemma3:12b/device/1486768 b/results/classifier/gemma3:12b/device/1486768 new file mode 100644 index 000000000..892666378 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1488363 b/results/classifier/gemma3:12b/device/1488363 new file mode 100644 index 000000000..c62957e80 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1490886 b/results/classifier/gemma3:12b/device/1490886 new file mode 100644 index 000000000..f5161294f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1490886 @@ -0,0 +1,33 @@ + +spice-qemu-char.c Assert + +spice-qemu-char.c:173: spice_chr_add_watch: Assertion `cond == G_IO_OUT' failed. +I trace the code virtio-console.c: +ret = qemu_chr_fe_write(vcon->chr, buf, len); + trace_virtio_console_flush_buf(port->id, len, ret); + + if (ret < len) { + VirtIOSerialPortClass *k = VIRTIO_SERIAL_PORT_GET_CLASS(port); + + /* + * Ideally we'd get a better error code than just -1, but + * that's what the chardev interface gives us right now. If + * we had a finer-grained message, like -EPIPE, we could close + * this connection. + */ + if (ret < 0) + ret = 0; + if (!k->is_console) { + virtio_serial_throttle_port(port, true); + if (!vcon->watch) { + vcon->watch = qemu_chr_fe_add_watch(vcon->chr, + G_IO_OUT|G_IO_HUP, + chr_write_unblocked, vcon); + } + } + } +and spice-qemu-char.c in function:spice_chr_add_watch +assert(cond == G_IO_OUT); +so run in this code,will trigger this assert. + +My qemu version is 2.3.0 and spice-server version is 0.12.5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1497711 b/results/classifier/gemma3:12b/device/1497711 new file mode 100644 index 000000000..fed5eb5ab --- /dev/null +++ b/results/classifier/gemma3:12b/device/1497711 @@ -0,0 +1,6 @@ + +tests/libqos/ahci.c:745: redundant condition ? + +[qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq || props.lba48' + + g_assert(!props->ncq || (props->ncq && props->lba48)); \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1499908 b/results/classifier/gemma3:12b/device/1499908 new file mode 100644 index 000000000..4558c42b6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1500175 b/results/classifier/gemma3:12b/device/1500175 new file mode 100644 index 000000000..1d964fd2b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1500175 @@ -0,0 +1,38 @@ + +unable to init msix vectors + +Using the latest stable (2.4.0.1) and earlier releases (at least down to 2.3.1), I am unable to run a qemu-system-arm virtualization on a Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. + +Command line: + +qemu-system-arm -device virtio-net,netdev=user.0 -drive file=pack,if=virtio,cache=writeback,discard=ignore -netdev user,id=user.0,hostfwd=tcp::3499-:22 -cdrom /opt/node-4.1.0/packer/2015-05-05-raspbian-wheezy.img -m 512M -boot once=d -vnc 0.0.0.0:87 -name packer-qemu -machine type=versatilepb -nographic + +Output: + +qemu-system-arm: -device virtio-net,netdev=user.0: unable to init msix vectors to 3 +qemu-system-arm: -drive file=pack,if=virtio,cache=writeback,discard=ignore: unable to init msix vectors to 2 +qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000 + +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=10000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +FPSCR: 00000000 +[1] 1322 abort qemu-system-arm -device virtio-net,netdev=user.0 -drive -netdev -cdrom -m \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1503 b/results/classifier/gemma3:12b/device/1503 new file mode 100644 index 000000000..ac757f654 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1503 @@ -0,0 +1,51 @@ + +Writing to readonly memory should call cpu_transaction_failed +Description of problem: +Currently if a guest writes to ROM memory on a system that doesn't have some other form of memory protection enabled, QEMU will silently ignore the write (https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L2432). Instead, it should call cpu_transaction_failed (similar to what happens when a MMIO operation fails in `io_writex` and other places). For CPUs that don't care, it'll continue to be ignored, but for other CPUs the user will get a warning (with `-d guest_errors`) or an exception as appropriate. +Steps to reproduce: +N/A +Additional information: +The documentation for do_transaction_failed says: + +``` +@do_transaction_failed: Callback for handling failed memory transactions +(ie bus faults or external aborts; not MMU faults) +``` + +which seems reasonably well suited for this case. Here's an overview of what different CPUs currently do if do_transaction_failed is called: + +alpha_cpu_do_transaction_failed: + +* raises a EXCP_MCHK + +arm_cpu_do_transaction_failed: + +* raises ARMFault_SyncExternal with EXCP_DATA_ABORT + +loongarch_cpu_do_transaction_failed: + +* raises EXCCODE_ADEM + +m68k_cpu_transaction_failed: + +* raises EXCP_ACCESS (M68040 only) + +mb_cpu_transaction_failed: + +* raises EXCP_HW_EXCP with ESR_EC_DATA_BUS + +mips_cpu_do_transaction_failed: + +* raises EXCP_DBE (data bus error) + +riscv_cpu_do_transaction_failed: + +* raises RISCV_EXCP_STORE_AMO_ACCESS_FAULT + +sparc_cpu_do_transaction_failed: + +* raises an MMU fault + +xtensa_cpu_do_transaction_failed + +* raises LOAD_STORE_PIF_ADDR_ERROR_CAUSE diff --git a/results/classifier/gemma3:12b/device/1510 b/results/classifier/gemma3:12b/device/1510 new file mode 100644 index 000000000..5bd4dbae3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1510 @@ -0,0 +1,93 @@ + +LibFuzzer: Deadly Signals +Description of problem: +``` +INFO: libFuzzer ignores flags that start with '--' +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1075449567 +INFO: Loaded 1 modules (323687 inline 8-bit counters): 323687 [0x558e9ece6000, 0x558e9ed35067), +INFO: Loaded 1 PC tables (323687 PCs): 323687 [0x558e9e7f5680,0x558e9ece5cf0), +./qemu-fuzz-i386: Running 1 inputs 1 time(s) each. +Running: crash-11075f8b34e355e114f92367a5e8b9bbb36a352d +Matching objects by name *usb* +Matching objects by name *ohci* +This process will try to fuzz the following MemoryRegions: + * bus master container[0] (size 0xffffffffffffffff) + * ohci[0] (size 0x100) + * bus master[0] (size 0xffffffffffffffff) +qemu-fuzz-i386: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +==1763255== ERROR: libFuzzer: deadly signal + #0 0x558e9ad46cb1 in __sanitizer_print_stack_trace (/home/hyper/qemu/build/qemu-fuzz-i386+0x1f71cb1) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #1 0x558e9acb9548 in fuzzer::PrintStackTrace() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4548) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #2 0x558e9ac9efc3 in fuzzer::Fuzzer::CrashCallback() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ec9fc3) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #3 0x7faa5444251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d) + #4 0x7faa54496a7b in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7faa54496a7b in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7faa54496a7b in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7faa54442475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7faa544287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7faa5442871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7faa54439e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x558e9b6c89d9 in usb_ep_get /home/hyper/qemu/build/../hw/usb/core.c:744:5 + #12 0x558e9b701fa4 in ohci_service_td /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:957:14 + #13 0x558e9b701fa4 in ohci_service_ed_list /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1122:21 + #14 0x558e9b6fa47b in ohci_frame_boundary /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1192:9 + #15 0x558e9cbe8b9c in timerlist_run_timers /home/hyper/qemu/build/../util/qemu-timer.c:576:9 + #16 0x558e9c2a9c7d in qtest_clock_warp /home/hyper/qemu/build/../softmmu/qtest.c:358:9 + #17 0x558e9c2a6411 in qtest_process_command /home/hyper/qemu/build/../softmmu/qtest.c:751:9 + #18 0x558e9c2a1f98 in qtest_process_inbuf /home/hyper/qemu/build/../softmmu/qtest.c:802:9 + #19 0x558e9c2a1db3 in qtest_server_inproc_recv /home/hyper/qemu/build/../softmmu/qtest.c:933:9 + #20 0x558e9c932980 in qtest_sendf /home/hyper/qemu/build/../tests/qtest/libqtest.c:600:5 + #21 0x558e9c932a84 in qtest_clock_step_next /home/hyper/qemu/build/../tests/qtest/libqtest.c:955:5 + #22 0x558e9ad86fed in generic_fuzz /home/hyper/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:715:17 + #23 0x558e9ad7aae3 in LLVMFuzzerTestOneInput /home/hyper/qemu/build/../tests/qtest/fuzz/fuzz.c:152:5 + #24 0x558e9aca0553 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ecb553) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #25 0x558e9ac8a2cf in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eb52cf) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #26 0x558e9ac90026 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ebb026) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #27 0x558e9acb9e42 in main (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4e42) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #28 0x7faa54429d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #29 0x7faa54429e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + #30 0x558e9ac84b94 in _start (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eafb94) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +qemu-fuzz-i386: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +==1763258== ERROR: libFuzzer: deadly signal + #0 0x558e9ad46cb1 in __sanitizer_print_stack_trace (/home/hyper/qemu/build/qemu-fuzz-i386+0x1f71cb1) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #1 0x558e9acb9548 in fuzzer::PrintStackTrace() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4548) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #2 0x558e9ac9efc3 in fuzzer::Fuzzer::CrashCallback() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ec9fc3) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #3 0x7faa5444251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d) + #4 0x7faa54496a7b in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7faa54496a7b in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7faa54496a7b in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7faa54442475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7faa544287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7faa5442871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7faa54439e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x558e9b6c89d9 in usb_ep_get /home/hyper/qemu/build/../hw/usb/core.c:744:5 + #12 0x558e9b701fa4 in ohci_service_td /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:957:14 + #13 0x558e9b701fa4 in ohci_service_ed_list /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1122:21 + #14 0x558e9b6fa47b in ohci_frame_boundary /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1192:9 + #15 0x558e9cbe8b9c in timerlist_run_timers /home/hyper/qemu/build/../util/qemu-timer.c:576:9 + #16 0x558e9c2a9c7d in qtest_clock_warp /home/hyper/qemu/build/../softmmu/qtest.c:358:9 + #17 0x558e9c2a6411 in qtest_process_command /home/hyper/qemu/build/../softmmu/qtest.c:751:9 + #18 0x558e9c2a1f98 in qtest_process_inbuf /home/hyper/qemu/build/../softmmu/qtest.c:802:9 + #19 0x558e9c2a1db3 in qtest_server_inproc_recv /home/hyper/qemu/build/../softmmu/qtest.c:933:9 + #20 0x558e9c932980 in qtest_sendf /home/hyper/qemu/build/../tests/qtest/libqtest.c:600:5 + #21 0x558e9c932a84 in qtest_clock_step_next /home/hyper/qemu/build/../tests/qtest/libqtest.c:955:5 + #22 0x558e9ad86fed in generic_fuzz /home/hyper/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:715:17 + #23 0x558e9ad7aae3 in LLVMFuzzerTestOneInput /home/hyper/qemu/build/../tests/qtest/fuzz/fuzz.c:152:5 + #24 0x558e9aca0553 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ecb553) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #25 0x558e9aca1175 in fuzzer::Fuzzer::TryDetectingAMemoryLeak(unsigned char const*, unsigned long, bool) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ecc175) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #26 0x558e9ac8a317 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eb5317) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #27 0x558e9ac90026 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ebb026) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #28 0x558e9acb9e42 in main (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4e42) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) + #29 0x7faa54429d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #30 0x7faa54429e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + #31 0x558e9ac84b94 in _start (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eafb94) (BuildId: 49539853a6c034db6a511d608192f681fdffa439) +``` +Steps to reproduce: +1. ./qemu-fuzz-i386 --fuzz-target=generic-fuzz-ohci +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1511887 b/results/classifier/gemma3:12b/device/1511887 new file mode 100644 index 000000000..70478d922 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1511887 @@ -0,0 +1,35 @@ + +USB device 1.1 not correctly passedthru from Linux host to Windows guest + +I have USB Digital Oscilloscope which works great on pure Windows machine but not work on virtualized one. I tried passthru the device from my Debian Jessie (64bit) host machine to Windows 7 (32bit) guest machine but unfortunately it does not work very well. It looks that device is passed thru so Windows machine knows about new device and loads HID device driver for it but the device driver failed to start the device and details of an error provided by device manager is "This device cannot start" Code 10. + +Installed Qemu version: 2.1+dfsg-12+deb8u4 0 + +USB device spec: Dynon Instruments ELAB-080, USB 1.1 + +On linux host computer +--------------------------- +lsusb identify it as: +Bus 003 Device 009: ID 13a3:0001 + +lsusb -t identify it as: +/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M + |__ Port 1: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 12M + +This is how I started my Windows guest machine +------------------------------------------------------ +kvm -cpu host \ + -m 2048MiB \ + -hda test.vdi \ + -ctrl-grab \ + -parallel /dev/parport0 \ + -usbdevice host:13a3:0001 + +...also instead of last line I tried this one: + -device usb-host,vendorid=0x13a3,productid=0x0001 + +none of them help to properly handle my device inside guest machine. + +Only one time the Windows guest machine properly start the device so software for that oscilloscope can identify the Oscilloscope and measure for a while but unfortunately after I guess 5 seconds of measurement the device was disconnected from Windows and never start working again even after couple of restarts of guest machine even after plug and unplug it's USB cable and power cable. + +I searched for a solution or some clues to get it work but none of my searching over the internet was successful. Because device works on pure Windows but not work on virtualized one, I think there is a problem with handling not standard USB devices (like sticks, keyboards, mouses etc.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1518969 b/results/classifier/gemma3:12b/device/1518969 new file mode 100644 index 000000000..b1a630a16 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1518969 @@ -0,0 +1,29 @@ + +Instance of QEMU doesn't unplug virtio scsi disk after device_del and drive_del commands + +device_del and drive_del commands don't cause virtio disk detaching + +Steps to reproduce: +1. Run instance + +2. Attach virtio scsi disk + +3. Reboot instance + +4. Immediately after reboot detach disk with QEMU commands: +device_del +drive_del + +Expected result: +Disk should be detached anyway + +Actual: +Domain info contains attached disk even after waiting long period of time(5 min in my case). + +Additional info: +QEMU process: +root 29010 42.6 1.9 562036 61272 ? Rl 03:42 0:01 /usr/bin/qemu-system-x86_64 -name instance-00000069 -S -machine pc-i440fx-trusty,accel=tcg,usb=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid d2418536-2547-4740-96b5-0d4f1d74b9f3 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=1fd8f69a-909b-4ed1-aae9-4fc9318fc622,uuid=d2418536-2547-4740-96b5-0d4f1d74b9f3,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000069.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/kernel -initrd /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/ramdisk -append root=/dev/vda console=tty0 console=ttyS0 no_timer_check -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk.config,if=none,id=drive-ide0-1-1,readonly=on,format=raw,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=18,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:1a:10:3d,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +QEMU version: +qemu-system-x86_64 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.19), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1522 b/results/classifier/gemma3:12b/device/1522 new file mode 100644 index 000000000..940036348 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1522 @@ -0,0 +1,41 @@ + +Floppy controller returns the wrong thing for multitrack reads which span tracks +Description of problem: +I've just discovered that the Minix 1 and 2 operating systems no longer boot on qemu. + +Investigation reveals the following: + +- when Minix reads a 1024-byte block from disk, it issues a two-sector multitrack read to the FDC. +- if the FDC runs out of sectors when it's on head 0, it automatically switches to head 1 (this is correct). +- if the FDC runs out of sectors when it's on head 1, it stops the transfer (which is what is supposed to happen). + +What qemu does for the latter case is that it will automatically seek to the next track and switch to head 0. It then sets the SEEK COMPLETE bit in the status register. Minix sees this but isn't expecting it, because this shouldn't be emitted for reads and writes, and fails thinking it's an error. + +For example, here's the logging for such a transfer: + +``` +FLOPPY: Start transfer at 0 1 4f 11 (2878) +FLOPPY: direction=1 (1024 - 10240) +FLOPPY: copy 512 bytes (1024 0 10240) 0 pos 1 4f (17-0x00000b3e 0x00167c00) +FLOPPY: seek to next sector (1 4f 11 => 2878) <--- reads the last sector of head 1 track 0x4f +FLOPPY: copy 512 bytes (1024 512 10240) 0 pos 1 4f (18-0x00000b3f 0x00167e00) +FLOPPY: seek to next sector (1 4f 12 => 2879) <--- attempt to move to the next sector, which fails +FLOPPY: seek to next track (0 50 01 => 2879) <--- moved to next track, which shouldn't happen +FLOPPY: end transfer 1024 1024 10240 +FLOPPY: transfer status: 00 00 00 (20) <--- status report +``` + +Transfer status 20 is the SEEK COMPLETE bit. For a normal head switch, that should be 04 (with the NOW ON HEAD 1 bit set). + +For reference, see page 5-13 of the uPD765 datasheet here: https://www.cpcwiki.eu/imgs/f/f3/UPD765_Datasheet_OCRed.pdf It says: + +> IF MT is high, a multitrack operation is performed. +> If MT = 1 after finishing read/write operation on side 0, +> FDC will automatically start command searching for sector +> 1 on side 1 +Steps to reproduce: +1. `qemu-system-i386 --fda images/minix-2.0-root-720kB.img` +2. Press = to boot. +3. Observe the 'Unrecoverable Read` errors as the ramdisk is loaded. (The system will still boot, but will then crash if you try to do anything due to a corrupt ramdisk.) + +[minix-2.0-root-720kB.img.bz2](/uploads/77d34db96f353d92cdb2d01928b8fc01/minix-2.0-root-720kB.img.bz2) diff --git a/results/classifier/gemma3:12b/device/1523246 b/results/classifier/gemma3:12b/device/1523246 new file mode 100644 index 000000000..0918f4fdf --- /dev/null +++ b/results/classifier/gemma3:12b/device/1523246 @@ -0,0 +1,16 @@ + +Virtio-blk does not support TRIM + +When model=virtio is used, TRIM is not supported. + +# mount -o discard /dev/vda4 /mnt +# mount | tail -1 +/dev/vda4 on /mnt type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) +# fstrim /mnt/ +fstrim: /mnt/: the discard operation is not supported + +Booting without model=virtio allows using TRIM (in Windows as well). + +Full QEMU line: + +qemu-system-x86_64 -enable-kvm -cpu host -bios /usr/share/ovmf/ovmf_x64.bin -smp 2 -m 7G -vga qxl -usbdevice tablet -net nic,model=virtio -net user -drive discard=unmap,detect-zeroes=unmap,cache=none,file=vms/win10.hd.img.vmdk,format=vmdk,if=virtio \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1523811 b/results/classifier/gemma3:12b/device/1523811 new file mode 100644 index 000000000..20366aaa5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1523811 @@ -0,0 +1,28 @@ + +USB assert failure on dev-storage.c + +On executing the attached python script in the guest OS, QEMU dies with assert failure: + +[run python script in guest root shell] +# python a.py + +[host message] +qemu-system-x86_64: hw/usb/dev-storage.c:445: usb_msd_handle_data: Assertion `le32_to_cpu(s->csw.residue) == 0' failed. +Aborted (core dumped) + + +When I detach the kernel driver and send CBW and reattach it again, without conforming to the command/data/status protocol, QEMU dies. +I think this is due to misimplementation of Command/Data/Status protocol in Bulk-only transfer. +This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines. +Before running python script, make sure to change a.py that it should points to usb mass storage's vid and pid. + +QEMU was running on these environment : +[CPU model] Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz +[qemu version] QEMU 2.5.0-rc2 (compiled from source, gcc 4.8.4) +[host info] Ubuntu 14.04.3, x86_64, 3.19.0-32-generic +[guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic +[QEMU argument] +x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2.5 \ + -m 512 \ + --usbdevice disk:format=qcow2:../usb.img.5 \ + --enable-kvm \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1525123 b/results/classifier/gemma3:12b/device/1525123 new file mode 100644 index 000000000..6126b8862 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1525123 @@ -0,0 +1,39 @@ + +USB assert failure on hcd-uhci.c + +When inserting the attached kernel moudle in the guest OS, QEMU quits with therse assert failure: + + +[insert kernel module in guest root shell] +root@qemu:~# insmod mymod.ko +root@qemu:~# +Connection closed by foreign host. + +[host message] +qemu-system-x86_64: hw/usb/core.c:718: usb_ep_get: Assertion `pid == 0x69 || pid == 0xe1' failed. +Aborted + +The cause of this bug is due to misimplementation of UHCI. +According to Intel's UHCI design guide, packet identification in transfer descriptor should have one of these three value : IN (69h), OUT (E1h), and SETUP (2Dh). Any other value in this field shoudl cause HALT OF only HOST CONTROLLER. +However, due to misimplementation in QEMU, not only host controller halts, but QEMU itself exits with assertion failure. +This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines. + +[How to run exploit code] +Prepare linux kernel's source header, then type these lines in root shell. +# make +# insmod mymod.ko + +It needs uhci-hcd.h from linux kernel source. +I attached linux 3.18.24's uhci-hcd.h for tempory measure; You should get proper version of uhci-hcd.h. +In the following envrionment, this exploit worked, exiting whole QEMU, not only USB. + +QEMU was running on these environment : +[CPU model] Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz +[qemu version] QEMU 2.5.0-rc3 (compiled from source, gcc 4.8.4) +[host info] Ubuntu 14.04.3, x86_64, 3.19.0-32-generic +[guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic +[QEMU argument] +x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2 \ + -m 512 \ + --usbdevice disk:format=qcow2:../usb.img \ + --enable-kvm \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1527 b/results/classifier/gemma3:12b/device/1527 new file mode 100644 index 000000000..d098cc007 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1527 @@ -0,0 +1,4 @@ + +-blockdev option missing host_device documenation and command line help support +Additional information: +We recommend -blockdev in the documentation as the preferred way to configure storage backends but the online help isn't useful. We also seem to be missing information for some of the blockdev drivers, for example host_device. diff --git a/results/classifier/gemma3:12b/device/1529449 b/results/classifier/gemma3:12b/device/1529449 new file mode 100644 index 000000000..78dd37eae --- /dev/null +++ b/results/classifier/gemma3:12b/device/1529449 @@ -0,0 +1,4 @@ + +serial is required for -device nvme + +I am not exactly sure if this is a bug, but I don't see why the option "serial" is required for -device nvme like drive. Truth is it seem to accept random string as its value anyway, if that's the case, couldn't qemu just generate one for it when it's not specified? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1529859 b/results/classifier/gemma3:12b/device/1529859 new file mode 100644 index 000000000..38d0dea05 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1529859 @@ -0,0 +1,49 @@ + +qemu 2.5.0 ivshmem segfault with msi=off option + +Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev socket,path=/tmp/ivshmem_socket,id=ivshmemid" + +Causes segfault because, s->msi_vectors is not initialized and s->msi_vectors == 0. + +Does ivshmem exactly need this line ? : + +s->msi_vectors[vector].pdev = pdev; + +It makes no sence for me. + +Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault + +--- + hw/misc/ivshmem.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +index f73f0c2..2087d5e 100644 +--- a/hw/misc/ivshmem.c ++++ b/hw/misc/ivshmem.c +@@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * + int eventfd = event_notifier_get_fd(n); + CharDriverState *chr; + +- s->msi_vectors[vector].pdev = pdev; +- + chr = qemu_chr_open_eventfd(eventfd); + + if (chr == NULL) { +@@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) + } + + if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +- msix_uninit_exclusive_bar(dev); ++ msix_uninit_exclusive_bar(dev); + } +- +- g_free(s->msi_vectors); ++ ++ if(s->msi_vectors) ++ g_free(s->msi_vectors); + } + + static bool test_msix(void *opaque, int version_id) +-- +2.3.6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1530035 b/results/classifier/gemma3:12b/device/1530035 new file mode 100644 index 000000000..785ce5ee5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1530035 @@ -0,0 +1,24 @@ + +usb-host: ATI Technologies, Inc. TV Wonder acts as a different device if used + +Title says it all. If you try to use the "ATI Technologies, Inc. TV Wonder" USB 1.1 TV Tuner for passthrough under any OS that has drivers for the device, the usb-host driver will confuse itself and give the device a new PID number for Linux. + +Tested on ReactOS and Windows XP with stable QEMU package from pacman on Arch Linux. + +Commands used: sudo qemu-system-x86_64 -enable-kvm -hda ~/QEMU/hd/winxp.img -usb -device usb-host,hostbus=2,hostaddr=3 -vga vmware + +Before starting qemu-kvm, lsusb reports: +[ +Bus 002 Device 003: ID 0528:7561 ATI Technologies, Inc. TV Wonder +] + +After starting qemu-kvm, usb-host and lsusb report: +[ +libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/003: No such file or directory + +The device in Bus 2, Device 3 is gone and it appears as this instead: +Bus 002 Device 005: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) D-Link V100 +] + +This weird effect only lasts until you unplug the TV Wonder. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1534683 b/results/classifier/gemma3:12b/device/1534683 new file mode 100644 index 000000000..b7e0d2dfa --- /dev/null +++ b/results/classifier/gemma3:12b/device/1534683 @@ -0,0 +1,13 @@ + +no mouse cursor / qxl / windows seven guest + +Hello, +When i'm using qxl graphic card with qemu 2.4.1 , and sdl2 client ( display ) , in a windows seven guest vm , there's no mouse cursor. +I'm using last qxl driver. + +With windows8.1 , there is no problem, mouse cursor is present. + +I need this to use two monitor with a windows guest, + +any suggestions are welcome, +Regards, \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1536487 b/results/classifier/gemma3:12b/device/1536487 new file mode 100644 index 000000000..b225eee13 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1536487 @@ -0,0 +1,24 @@ + +Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1 + +When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out: + + qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg' + +This appears to be related to the addition of a DMA interface to fw_cfg last October: + + http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04568.html + +"info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled: + + bus: main-system-bus + type System + ... + dev: fw_cfg_io, id "" + iobase = 1296 (0x510) + dma_iobase = 1300 (0x514) + dma_enabled = true + +Incidentally, this guest had just undergone a migration from QEMU 2.4.0 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration. + +It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1538 b/results/classifier/gemma3:12b/device/1538 new file mode 100644 index 000000000..8c5bf4205 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1538 @@ -0,0 +1,2 @@ + +igd.c gives up IGD legacy mode if no option ROM found diff --git a/results/classifier/gemma3:12b/device/1542 b/results/classifier/gemma3:12b/device/1542 new file mode 100644 index 000000000..ff7adaf50 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1542 @@ -0,0 +1,14 @@ + +Non-Executable PMP regions of size less than 4K trigger instruction access faults non-deterministically +Description of problem: +When a non-executable PMP region of size less than 4K (page size) with a start address that is not 4K-aligned is created, QEMU will non-deterministically dispatch instruction access faults when instructions are executed from the PMP-covered region (will in some cases, won't in others, based on the current TLB state) +Steps to reproduce: +1. Create a PMP region of size less than 4K, that is not aligned to the start of the page, make it non-executable +2. Flush TLB with `sfence.vma x0, x0` +3. Jump to the start of the pmp-protected page and start executing instructions +4. Notice that no instruction access fault is reported once we reach the protected region inside the page +Additional information: +@rth7680 I believe this is at least partially an unintentional result of this commit that you authored: 7e0d9973ea665bf459b2dbd173d0e51bc6ca5216, which modified the behavior of `get_page_addr_code_hostp` probes to probe a single byte, instead of a full page size (signaled by passing 0). +This means that we initially probe the first byte of the page, see that no PMP faults are raised, and then assume that no other bytes in the page can cause a PMP fault. + +Note that I believe that simply changing this back to 0 from 1 is not enough, as this will likely simply reintroduce the issue I originally reported in #1053. diff --git a/results/classifier/gemma3:12b/device/1543 b/results/classifier/gemma3:12b/device/1543 new file mode 100644 index 000000000..787b51bad --- /dev/null +++ b/results/classifier/gemma3:12b/device/1543 @@ -0,0 +1,2 @@ + +Heap-use-after-free in e1000e_receive_internal diff --git a/results/classifier/gemma3:12b/device/1543057 b/results/classifier/gemma3:12b/device/1543057 new file mode 100644 index 000000000..1ac4a8920 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1543057 @@ -0,0 +1,17 @@ + +Warnings are treated as errors + +System: Ubuntu 14.04, 32bit +Kernel: 3.13.0-55-generic +Qemu: v. 2.2.50 + +Error msg: + +hw/acpi/pcihp.c: In function ‘acpi_pcihp_pc_no_hotplug’: +hw/acpi/pcihp.c:117:34: error: ‘PCIDevice’ has no member named ‘qdev’ + return (pc->is_bridge && !dev->qdev.hotplugged) || !dc->hotpluggable; + ^ +hw/acpi/pcihp.c:118:1: error: control reaches end of non-void function [-Werror=return-type] + } + ^ +cc1: all warnings being treated as errors \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1550743 b/results/classifier/gemma3:12b/device/1550743 new file mode 100644 index 000000000..c2d819b4a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1550743 @@ -0,0 +1,27 @@ + +connect low speed host devices to qemu ehci does not work + +$ qemu-system-i386 -hda my_x86.img -device ich9-usb-ehci1,id=ehci -device usb-host,vendorid=0x045e,productid=0x071d -serial stdio +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) +qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed) + +Which is obviously wrong. The ehci specification states: + +Low-speed device, release ownership of port <= Table 2-16. + +Table 2-6: + +Number of Companion Controller (N_CC). This field indicates the number of +companion controllers associated with this USB 2.0 host controller. +A zero in this field indicates there are no companion host controllers. Port-ownership +hand-off is not supported. Only high-speed devices are supported on the host controller +root ports. +A value larger than zero in this field indicates there are companion USB 1.1 host +controller(s). Port-ownership hand-offs are supported. High, Full- and Low-speed +devices are supported on the host controller root ports. + +Which is not longer true, as for example skylake and baytrail offers a dual usb stack of ehci and xhci. In that case, EHCI handles the low speed device as well. + +brgds, +Bert \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1557033 b/results/classifier/gemma3:12b/device/1557033 new file mode 100644 index 000000000..3078928a5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1557033 @@ -0,0 +1,17 @@ + +Persistent malfunction after guest shutdown/reboot + +Running the VM the first time after the host has booted up is completely fine, no issues at all. However, after shutting down or restarting the VM, certain problems occur. In the Windows 10 VM, it may throw a SYSTEM_THREAD_EXCEPTION error on bootup, and other times it simply won't use the VirtIO drive. Before the latest update of QEMU 2.5.0, I have had no problems. + +Recently, I've also downgraded my kernel in order to solve some problems related to Haswell. This is probably the same time I've got the 2.5.0 update. When I did this, I could no longer boot into my main image due to similar problems. I've had to also update the VirtIO storage driver with a new image installation. Before I figured that everything worked fine on a host reboot, the installer would spit out an error that it could not modify the partitions of the drive. Everything else worked fine with SATA or IDE configuration, but not VirtIO. I shouldn't need to restart my computer after shutting down the computer. + +I've tried using QEMU with the latest Linux kernel (4.4.x) with the exact same result. + +Here is what I have configured: +- Arch Linux with linux-lts (4.1.19-1-lts) +- QEMU 2.5.0 +- VirtIO drivers v 0.1.113 +- Windows 10 from MSDN +- vfio PCI Passthrough of NVIDIA 970 + +I'm not sure how to get any more logs so if you need more info I'll be glad to provide it \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1563 b/results/classifier/gemma3:12b/device/1563 new file mode 100644 index 000000000..d6b8bee80 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1563 @@ -0,0 +1,4 @@ + +lsi53c895a: DMA reentrancy issue leads to stack overflow (CVE-2023-0330) +Description of problem: +See https://bugzilla.redhat.com/show_bug.cgi?id=2160151. diff --git a/results/classifier/gemma3:12b/device/1569 b/results/classifier/gemma3:12b/device/1569 new file mode 100644 index 000000000..4cbcf1bb4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1569 @@ -0,0 +1,28 @@ + +NVMe FS operations hang after suspending and resuming both guest and host +Description of problem: +Hello and thank you for your work on QEMU! + +Using the NVMe driver with my Seagate FireCuda 530 2TB M.2 works fine until I encounter this problem, which is reliably reproducible for me. + +When I suspend the guest and then suspend (s2idle) my host all is well until I resume the guest (manually with `virsh dompmwakeup $VMNAME`, after the host has resumed). Although the guest resumes and is interactive, it seems that anything involving filesystem operations hang forever and do not return. + +Suspending and resuming the Linux guest seems to work perfectly if I don't suspend/resume the host. + +Ultimately what I'm wanting to do is share the drive between VMs with qemu-storage-daemon. I can reproduce the problem in that scenario in much the same way. Using PCI passthrough with the same VM and device works fine and doesn't exhibit this problem. + +Hopefully that's clear enough - let me know if there's anything else I can provide. +Steps to reproduce: +1. Create a VM with a dedicated NVMe disk. +2. Boot an ISO and install to the disk. +3. Verify that suspend and resume works when not suspending the host. +4. Suspend the guest. +5. Suspend the host. +6. Wake the host. +7. Wake the guest. +8. Try just about anything that isn't likely already cached somewhere: `du -s /etc`. +Additional information: +I've attached the libvirt domain XML[1] and libvirtd debug logs for QEMU[2] ("1:qemu") that covers suspending the guest & host, resuming host & guest and doing something to cause a hang. I tried to leave enough time afterwards for any timeout to occur. + +1. [nvme-voidlinux.xml](/uploads/1dea47af096ce58175f7aa526eca455e/nvme-voidlinux.xml) +2. [nvme-qemu-debug.log](/uploads/42d3bed456a795069023a61d38fa5ccd/nvme-qemu-debug.log) diff --git a/results/classifier/gemma3:12b/device/157 b/results/classifier/gemma3:12b/device/157 new file mode 100644 index 000000000..0031d62bf --- /dev/null +++ b/results/classifier/gemma3:12b/device/157 @@ -0,0 +1,2 @@ + +Xbox One controller USB passthrough disconnections and stops diff --git a/results/classifier/gemma3:12b/device/1572 b/results/classifier/gemma3:12b/device/1572 new file mode 100644 index 000000000..2f6511114 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1572 @@ -0,0 +1,2 @@ + +Assertion !rss_info->enabled failed in e1000e_write_lgcy_rx_descr diff --git a/results/classifier/gemma3:12b/device/1572959 b/results/classifier/gemma3:12b/device/1572959 new file mode 100644 index 000000000..284e74707 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1572959 @@ -0,0 +1,8 @@ + +bcm2835_property: inconsistent values when both setting and querying the framebuffer + +As the framebuffer settings are copied into the result message before it is reconfigured, inconsistent behavior can happen when, for instance, you set with a single message the width, height, and depth, and ask at the same time to allocate the buffer and get the pitch and the size. + +In this case, the reported pitch and size would be incorrect as they were computed with the initial values of width, height and depth, not the ones the client requested. + +Attached is a patch also sent to the qemu-devel mailing list. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1576 b/results/classifier/gemma3:12b/device/1576 new file mode 100644 index 000000000..831118dc9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1576 @@ -0,0 +1,29 @@ + +Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails +Description of problem: +Loading the VM state fails with: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load pcie-root-port:parent_obj.parent_obj.parent_obj +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:1c.0/pcie-root-port' +qemu-system-x86_64: Error -22 while loading VM state +``` +Steps to reproduce: +Used the following script with the first argument being a build directory of v8.0.0-rc2 and the second a build directory of v7.2.0 +``` +#!/bin/bash +rm /tmp/disk.qcow2 +args=" + -device pcie-root-port,multifunction=on,bus=pcie.0,addr=1c.0,port=1,chassis=1 + -machine type=pc-q35-7.2" +$1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G +$1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF +{"execute": "qmp_capabilities"} +{"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } +{"execute": "quit"} +EOF +$2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap +``` +Additional information: +Bisecting shows that 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") is the first bad commit. diff --git a/results/classifier/gemma3:12b/device/1576347 b/results/classifier/gemma3:12b/device/1576347 new file mode 100644 index 000000000..33697e392 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1576347 @@ -0,0 +1,27 @@ + +Only one NVMe device is usable in Windows (10) guest + +Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +QEMU version: 2.5.0 + +Kernel: 4.5.1 (Arch Linux) + +When there are two NVMe devices specified, only the second one will be usable in Windows. The following error is shown under "Device status" of the failed NVMe controller in Device Manager: + +"This device cannot start. (Code 10) + +The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect." + +The only thing seems suspicious to me is that the nvme emulation in qemu does not have WWN/EUI-64 set for the devices, though I have no idea at all whether that is mandatory: + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1577 b/results/classifier/gemma3:12b/device/1577 new file mode 100644 index 000000000..5bad61870 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1579306 b/results/classifier/gemma3:12b/device/1579306 new file mode 100644 index 000000000..f362925f9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1579306 @@ -0,0 +1,15 @@ + +usb-uas does not work in Windows (10) guest + +When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest: + +"The device cannot start. (Code 10) + +{Operation Failed} +The requested operation was unsuccessful" + +If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well: + +"qemu-system-x86_64: usb_uas_handle_control: unhandled control request" + +If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/158 b/results/classifier/gemma3:12b/device/158 new file mode 100644 index 000000000..ea3549712 --- /dev/null +++ b/results/classifier/gemma3:12b/device/158 @@ -0,0 +1,2 @@ + +qemu system emulator crashed when using xhci usb controller diff --git a/results/classifier/gemma3:12b/device/1580459 b/results/classifier/gemma3:12b/device/1580459 new file mode 100644 index 000000000..b1b3dccfa --- /dev/null +++ b/results/classifier/gemma3:12b/device/1580459 @@ -0,0 +1,16 @@ + +Windows (10?) guest freezes entire host on shutdown if using PCI passthrough + +Problem: after leaving a Windows VM that uses PCI passthrough (as we do for gaming graphics cards, sound cards, and in my case, a USB card) running for some amount of time between 1 and 2 hours (it's not consistent with exactly how long), and for any amount of time longer than that, shutting down that guest will, right as it finishes shutting down, freeze the host computer, making it require a hard reboot. Unbinding (or in the other user's case, unbinding and THEN binding) any PCI device in sysfs, even one that has nothing to do with the VM, also has the same effect as shutting down the VM (if the VM has been running long enough). So, it's probably an issue related to unbinding and binding PCI devices. + +There's a lot of info on this problem over at https://bbs.archlinux.org/viewtopic.php?id=206050 +Here's a better-organized list of main details: +-at least 2 confirmed victims of this bug; 2 (including me) have provided lots of info in the link +-I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific) +-issue affects my Windows 10 guest and others' Windows guests, but not my Arch Linux guest (the others don't have non-Windows guests to test) +-I'm using libvirt but the other user is not, so it's not an issue with libvirt +-It seems to be version non-specific, too. I first noticed it at, or when testing versions still had the issue at (whichever version is lower), Linux 4.1 and qemu 2.4.0. It still persists in all releases of both since, including the newest ones. +-I can't track down exactly what package downgrade can fix it, as downgrading further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying changes such as downgrading ncurses, meaning I don't know whether it's a bug in QEMU, the Linux kernel, or some weird seemingly unrelated thing. +-According to the other user, "graphics intensive gameplay (GTA V) can cause the crash to happen sooner," as soon as "15 minutes" +-Also, "bringing up a second passthrough VM with separate hardware will cause the same crash," and "bringing up another VM before the two-hour mark will not result in a crash," further cementing that it's triggered by the un/binding of PCI devices. +-This is NOT related to the very similar bug that can be worked around by not passing through the HDMI device or sound card. Even when we removed all traces of any sort of sound card from the VM, it still had the same behavior. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1581308 b/results/classifier/gemma3:12b/device/1581308 new file mode 100644 index 000000000..7fd95c237 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1581308 @@ -0,0 +1,17 @@ + +ohci doesn't check the 'num-ports' property + +command: +qemu-system-x86_64 -m 1024 -enable-kvm /root/centos6.img -enable-kvm -device pci-ohci,num-ports=100,masterbus=1 + +The ohci doesn't check the 'num-ports' property and would case an out-of-bands write,crash the qemu process. + + ohci->num_ports = num_ports; + if (masterbus) { + USBPort *ports[OHCI_MAX_PORTS]; + for(i = 0; i < num_ports; i++) { + ports[i] = &ohci->rhport[i].port; + } + +The version of qemu is 2.6.0 release from +http://wiki.qemu-project.org/download/qemu-2.6.0.tar.bz2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1585008 b/results/classifier/gemma3:12b/device/1585008 new file mode 100644 index 000000000..8e5da80ea --- /dev/null +++ b/results/classifier/gemma3:12b/device/1585008 @@ -0,0 +1,16 @@ + +Windows 7 guests hang on bootup when qxl video is used + +I installed libvirt-bin and virt-manager on Ubuntu 16.04. I created a new VM for Windows 7, basically with default settings, which includes qxl video.. The Windows boot process hangs with the "Starting Windows" animation. CPU and disk I/O drop to zero, and it continues animating.... forever and ever... It never finishes booting. But it doesn't fully "hang" either: the animation continues to animate. + +As a workaround, I set the video mode to "Cirrus" and then Windows boots but it is slow and limited. And also apparently to be avoided: + +https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ + +I can confirm it's only when qxl is enabled, because if I switch from Cirrus back to qxl, it hangs again - and going back to Cirrus again "fixes" the problem. + +This issue is also reported elsewhere: + +http://serverfault.com/questions/776406/windows-7-setup-hangs-at-starting-windows-using-proxmox-4-2 + +https://forum.proxmox.com/threads/win7-setup-hangs-in-proxmox-ve-4-2.27388/ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1587970 b/results/classifier/gemma3:12b/device/1587970 new file mode 100644 index 000000000..ff2dc2c71 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1587970 @@ -0,0 +1,6 @@ + +QEMU Crashes when attaching USB 3.00 devices to xhci bus + +Using qemu 2.6 with a windows7 32-bit VM, if I plug a USB 3.0 memory stick in to a USB 3.0 port, then pass it through to the VM via the monitor (device_add usb-host,bus=xhci.0,hostbus=xx,hostaddr=xx,id=stick1) then qemu asserts and dies - I have seen 2 different asserts one is from the xchi module - Assertion `intr->er_full, and one is in core.c (line 400 I IIRCC) with "Assertion dev->state == 3 failed" +Tried to work around by only passing in an ehci controller to the VM, but then if I attach a usb 3.0 memory stick to that it doesn't work in windows. +I have made sure the xhci drivers in the windows VM are up to date, latest version of SeaBios etc, but at the moment, I have had to disable xhci in my system bios and just use ehci for everything. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1589564 b/results/classifier/gemma3:12b/device/1589564 new file mode 100644 index 000000000..b8fd3fdc5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1589564 @@ -0,0 +1,21 @@ + +qemu/hw/scsi/scsi-disk.c:2741: possible missing break ? + +qemu/hw/scsi/scsi-disk.c:2741] -> [qemu/hw/scsi/scsi-disk.c:2745]: (warning) Variable 'cdb1' is reassigned a value before the old one has been used. 'break;' missing? +qemu/hw/scsi/scsi-disk.c:2742] -> [qemu/hw/scsi/scsi-disk.c:2746]: (warning) Variable 'group_number' is reassigned a value before the old one has been used. 'break;' missing? + +Source code is + + case 1: + /* 10-byte CDB. */ + r->cdb1 = req->cmd.buf[1]; + r->group_number = req->cmd.buf[6]; + case 4: + /* 12-byte CDB. */ + +Also, + +[qemu/hw/scsi/scsi-disk.c:2063]: (warning) %lu in format string (no. 1) requires 'unsigned long' but the argument type is 'signed long'. +[qemu/hw/scsi/scsi-disk.c:2066]: (warning) %lu in format string (no. 1) requires 'unsigned long' but the argument type is 'signed long'. +[qemu/hw/scsi/scsi-disk.c:2069]: (warning) %lu in format string (no. 1) requires 'unsigned long' but the argument type is 'signed long'. +[qemu/hw/scsi/scsi-disk.c:2083]: (warning) %lu in format string (no. 2) requires 'unsigned long' but the argument type is 'signed long'. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/159 b/results/classifier/gemma3:12b/device/159 new file mode 100644 index 000000000..1f8c015e1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/159 @@ -0,0 +1,2 @@ + +qemu-nbd -l and -s options don't work together diff --git a/results/classifier/gemma3:12b/device/1591628 b/results/classifier/gemma3:12b/device/1591628 new file mode 100644 index 000000000..5cd503ea4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1592315 b/results/classifier/gemma3:12b/device/1592315 new file mode 100644 index 000000000..96cab627e --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1597 b/results/classifier/gemma3:12b/device/1597 new file mode 100644 index 000000000..937f22489 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1597 @@ -0,0 +1,57 @@ + +Intel Arc A-Series GPUs VFIO passthrough no video out +Description of problem: +Once the VM is booted, the screen goes blank. +Steps to reproduce: +1. Passthough any Intel Arc A (Alchemist) series video card. +2. Boot VM. +3. Screen goes blank. +Additional information: +I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I start the VM that issue presents itself. + + + +kernel command line: + +``` +amd_iommu=on iommu=pt rd.driver.pre=vfio-pci pci=realloc iommu=1 i915.force_probe=* + +``` + +startup script: + +``` +#!/bin/bash +# Helpful to read output when debugging +set -x + +# Load the config file with our environmental variables +source "/etc/libvirt/hooks/kvm.conf" +source "/etc/libvirt/hooks/vmPreBootSetup" + +cpuPerf + +# Stop your display manager. If you're on kde it'll be sddm.service. Gnome users should use 'killall gdm-x-session' instead +systemctl stop gdm.service + +# Unbind VTconsoles +echo 0 > /sys/class/vtconsole/vtcon0/bind +echo 0 > /sys/class/vtconsole/vtcon1/bind + +# Avoid a race condition by waiting a couple of seconds. This can be calibrated to be shorter or longer if required for your system +sleep 2 + +modprobe -r drm_buddy intel_gtt video drm_display_helper cec ttm i915 + +# Unbind the GPU from display driver +virsh nodedev-detach $VIRSH_GPU_VIDEO +virsh nodedev-detach $VIRSH_GPU_AUDIO + +# Load VFIO kernel module +modprobe vfio +modprobe vfio_pci +modprobe vfio_iommu_type1 + +sleep 5s ; systemctl restart connman.service + +``` diff --git a/results/classifier/gemma3:12b/device/1597138 b/results/classifier/gemma3:12b/device/1597138 new file mode 100644 index 000000000..d1661f6b5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1600563 b/results/classifier/gemma3:12b/device/1600563 new file mode 100644 index 000000000..3eda2d382 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1600563 @@ -0,0 +1,17 @@ + +min_io_size is currently limited to size uint16_t + +I am using LVM VGs on MD-raid1 for hosting my KVM volumes. On the host, a VG looks like this: + +Disk /dev/vm/vol202a: 60 GiB, 64424509440 bytes, 125829120 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 131072 bytes / 131072 bytes + +In order to replicate the block device characteristics in the guest, I am using the following extra parameters: + +-set device.scsi0-0-0-0.logical_block_size=512 +-set device.scsi0-0-0-0.physical_block_size=4096 +-set device.scsi0-0-0-0.min_io_size=131072 + +This doesn't work as qemu complains that min_io_size needs to be of type uint16_t. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1603693 b/results/classifier/gemma3:12b/device/1603693 new file mode 100644 index 000000000..de99632ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1603779 b/results/classifier/gemma3:12b/device/1603779 new file mode 100644 index 000000000..cc91da43a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1603779 @@ -0,0 +1,19 @@ + +AC97 can allocate ~500MB of host RAM + +While working with qtest test cases generated via fuzzing with QEMU 2.5.0, I discovered some odd behavior for the AC97 virtual device with qemu-system-i386. If AC97_MIC_ADC_RATE is set to the value of 1, the QEMU process allocates over 500MB of additional host RAM. You probably would not normally notice this on a modern PC, except that I was using a "ulimit" command to restrict the maximum amount of virtual memory allowed for the QEMU process, so the process would crash with a SIGTRAP (signal 5) on the failed memory allocation. + +My minimized qtest code to reproduce the issue is: + +static void test_crash(void) +{ + uint64_t barsize; + dev = get_device(); + + dev_base[0] = qpci_iomap(dev, 0, &barsize); + dev_base[1] = qpci_iomap(dev, 1, &barsize); + qpci_device_enable(dev); + qpci_io_writew(dev, dev_base[0]+0x32, 0x00000001); +} + +I ran a "ulimit -sv 650000" command and then launched the tests/ac97-test binary with this crash test case included in it. I can then see the QEMU process crash on an allocation of 722538464 bytes. I can gradually increase the ulimit memory limit to ~1200000 and then no longer see the issue, hence my estimate of 500 MB of RAM allocated by the device. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1603785 b/results/classifier/gemma3:12b/device/1603785 new file mode 100644 index 000000000..67d60aea6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1603785 @@ -0,0 +1,12 @@ + +trace_usb_port_attach prints junk data + +Running qemu with tracing (-D ~/qemu_trace -d trace:\*) will result in a trace file with unprintable characters. + +example: usb_port_attach bus 0, port 1, devspeed <90>l<DB>.<D8>U, portspeed full+high + +The problem is in hw/usb/bus.c usb_mask_to_str. If speedmask doesn't match any of the defined speed nothing is written to *dest and uninitialized data is printed to the log. + +This happens with a real usb device that is forwarded into the machine. + +My qemu version is 2.6.0 but it looks like the problem exists in latest git also. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1604 b/results/classifier/gemma3:12b/device/1604 new file mode 100644 index 000000000..b7461eb3d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1604 @@ -0,0 +1,64 @@ + +Get wrong rom when loading 2 different firmware to 2 cpu. +Description of problem: +HI, I'm trying to model a machine with 2 cortex-m7 cpu. The 2 CPUs have their own address spaces. +and when loading rom to init sp and pc, the CPU1 would load the rom of CPU0, because it seems not check +address space here. +```c +void *rom_ptr_for_as(AddressSpace *as, hwaddr addr, size_t size) +{ + /* + * Find any ROM data for the given guest address range. If there + * is a ROM blob then return a pointer to the host memory + * corresponding to 'addr'; otherwise return NULL. + * + * We look not only for ROM blobs that were loaded directly to + * addr, but also for ROM blobs that were loaded to aliases of + * that memory at other addresses within the AddressSpace. + * + * Note that we do not check @as against the 'as' member in the + * 'struct Rom' returned by rom_ptr(). The Rom::as is the + * AddressSpace which the rom blob should be written to, whereas + * our @as argument is the AddressSpace which we are (effectively) + * reading from, and the same underlying RAM will often be visible + * in multiple AddressSpaces. (A common example is a ROM blob + * written to the 'system' address space but then read back via a + * CPU's cpu->as pointer.) This does mean we might potentially + * return a false-positive match if a ROM blob was loaded into an + * AS which is entirely separate and distinct from the one we're + * querying, but this issue exists also for rom_ptr() and hasn't + * caused any problems in practice. + */ + FlatView *fv; + void *rom; + hwaddr len_unused; + FindRomCBData cbdata = {}; + + /* Easy case: there's data at the actual address */ + rom = rom_ptr(addr, size); + if (rom) { + return rom; + } +``` +Steps to reproduce: +1. create a machine with 2 cortex-m7 cores and their own rom/ram. +2. Set different ram size for them. for example, cpu0 ram size:0x40000, cpu1 ram size:0x20000 +3. build firmware of 2 cpu. make sure the init SP(local at 0x0) is set to the top the ram. +4. use command: +``` +./qemu-system-arm -M mymachine -smp 2 \ +-device loader,file=./cpu0.elf,addr=0x0,cpu-num=0 \ +-device loader,file=./cpu1.elf,addr=0x0,cpu-num=1 \ +-serial stdio -serial tcp::5678,server=on,wait=off +``` +to start this machine. + +5. the cpu1 will panic when it try to use stack: +`qemu-system-arm: ../target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion failed.` + + +Sorry that I'm not sure whether this is an issue or I did something wrong. So post it here. +For local fix this problem, I add a func `rom_ptr_wit_as(addr,size,as)` to find a rom with addresspace check. +Is it proper? +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1606899 b/results/classifier/gemma3:12b/device/1606899 new file mode 100644 index 000000000..193b16151 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1606899 @@ -0,0 +1,12 @@ + +virtio-vga does not let guest poweroff properly + +I have a VM running rawhide (Fedora development) and I can't poweroff the machine when I enable virtio-vga. Reboot works correctly. Using QXL works also. The machine arrive to print the "Powering off" message (from Linux kernel) but then hangs. + +The command line is + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name rawhide -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu Haswell-noTSX -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 64216421-aec4-4ce4-aa52-aed9e4e31a1c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rawhide.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 -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 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/rawhide.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:11:43,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/rawhide.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice ipv4,addr=0.0.0.0,port=5900,disable-ticketing,image-compression=lz,seamless-migration=on,streaming-video=filter -device virtio-vga,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 virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + +I though was due to Virgl but disabling it does not change. + +I'm using Qemu 2.6.0 from Fedora 24. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/161 b/results/classifier/gemma3:12b/device/161 new file mode 100644 index 000000000..4b32ad2f0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/161 @@ -0,0 +1,2 @@ + +virtio-scsi gives improper discard sysfs entries diff --git a/results/classifier/gemma3:12b/device/1613 b/results/classifier/gemma3:12b/device/1613 new file mode 100644 index 000000000..04ea9d8a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1614 b/results/classifier/gemma3:12b/device/1614 new file mode 100644 index 000000000..1d1d04f1e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1614 @@ -0,0 +1,2 @@ + +Add option to chardev pty for setting a named link to the allocated pty diff --git a/results/classifier/gemma3:12b/device/1615823 b/results/classifier/gemma3:12b/device/1615823 new file mode 100644 index 000000000..63ef90b5c --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1617385 b/results/classifier/gemma3:12b/device/1617385 new file mode 100644 index 000000000..32f3ff657 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1618 b/results/classifier/gemma3:12b/device/1618 new file mode 100644 index 000000000..71749a939 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1618 @@ -0,0 +1,14 @@ + +intel-hda: SD_STS different behavior for byte write vs. word write +Description of problem: +The Intel HDA SD_STS register is accessible two different ways in QEMU: either it's the top 8 bits of a 32-bit access +or it's directly accessible as a byte. +On reads, the register behavior for SD_STS is identical whether accessed as a 32-bit read or an 8-bit read. +On writes, the behavior is different; when written to as an 8-bit write, the BCIS, FIFOE, and DESE bits implement the documented HDA behavior of RW1C (writing a 1 to a bit clears it). When written to as the top 8 bits of a 32-bit write, writing a 1 to a bit sets the bit -- so an attempt to clear a status bit instead unconditionally sets the status bit. +Steps to reproduce: +1. Write 32 bits at SD_CTL address with bit 27 set (FIFOE). This should clear FIFOE, but does not. +2. Read back SD_STS (SD_CTL address + 3) as a byte. The FIFOE bit will be set. +3. Write 8 bits at SD_STS address with bit 3 set (FIFOE). This should clear FIFOE, and it does. +4. Read back SD_STS as a byte. The FIFOE bit will be cleared. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1618431 b/results/classifier/gemma3:12b/device/1618431 new file mode 100644 index 000000000..52065e0aa --- /dev/null +++ b/results/classifier/gemma3:12b/device/1618431 @@ -0,0 +1,66 @@ + +windows hangs after live migration with virtio + +Several of our users reported problems with windows machines hanging +after live migrations. The common denominator _seems_ to be virtio +devices. +I've managed to reproduce this reliably on a windows 10 (+ +virtio-win-0.1.118) guest, always within 1 to 5 migrations, with a +virtio-scsi hard drive and a virtio-net network device. (When I +replace the virtio-net device with an e1000 it takes 10 or more +migrations, and without virtio devices I have not (yet) been able to +reproduce this problem. I also could not reproduce this with a linux +guest. Also spice seems to improve the situation, but doesn't solve +it completely). + +I've tested quite a few tags from qemu-git (v2.2.0 through v2.6.1, +and 2.6.1 with the patches mentioned on qemu-stable by Peter Lieven) +and the behavior is the same everywhere. + +The reproducibility seems to be somewhat dependent on the host +hardware, which makes investigating this issue that much harder. + +Symptoms: +After the migration the windows graphics stack just hangs. +Background processes are still running (eg. after installing an ssh +server I could still login and get a command prompt after the hang was +triggered... not that I'd know what to do with that on a windows +machine...) - commands which need no GUI access work, the rest just +hangs there on the command line, too. +It's also capable of responding to an NMI sent via the qemu monitor: +it then seems to "recover" and manages to show the blue sad-face +screen that something happened, reboots successfully and is usable +again without restarting the qemu process in between. +From there whole the process can be repeated. + +Here's what our command line usually looks like: + +/usr/bin/qemu -daemonize \ + -enable-kvm \ + -chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait -mon chardev=qmp,mode=control \ + -pidfile /var/run/qemu-server/101.pid \ + -smbios type=1,uuid=07fc916e-24c2-4eef-9827-4ab4026501d4 \ + -name win10 \ + -smp 6,sockets=1,cores=6,maxcpus=6 \ + -nodefaults \ + -boot menu=on,strict=on,reboot-timeout=1000 \ + -vga std \ + -vnc unix:/var/run/qemu-server/101.vnc \ + -no-hpet \ + -cpu kvm64,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce \ + -m 2048 \ + -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f \ + -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e \ + -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 \ + -device usb-tablet,id=tablet,bus=uhci.0,port=1 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ + -iscsi initiator-name=iqn.1993-08.org.debian:01:1ba48d46fb8 \ + -drive if=none,id=drive-ide0,media=cdrom,aio=threads \ + -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=200 \ + -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 \ + -drive file=/mnt/pve/data1/images/101/vm-101-disk-1.qcow2,if=none,id=drive-scsi0,cache=writeback,discard=on,format=qcow2,aio=threads,detect-zeroes=unmap \ + -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100 \ + -netdev type=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on \ + -device virtio-net-pci,mac=F2:2B:20:37:E6:D7,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 \ + -rtc driftfix=slew,base=localtime \ + -global kvm-pit.lost_tick_policy=discard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1622582 b/results/classifier/gemma3:12b/device/1622582 new file mode 100644 index 000000000..c5665da10 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1624726 b/results/classifier/gemma3:12b/device/1624726 new file mode 100644 index 000000000..02a46c7a8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1624726 @@ -0,0 +1,30 @@ + +Integrator/CP regression after QOM'ification of integratorcp.c + +The following command line no longer works (i.e. the guest does not boot) with QEMU 2.7.0: + + qemu-system-arm -M integratorcp -m 128M -kernel HelenOS-0.6.0-arm32-integratorcp.boot + +The HelenOS image can be downloaded here: + + http://www.helenos.org/releases/HelenOS-0.6.0-arm32-integratorcp.boot + +I did git bisect and came to this revision: + +a1f42e0c9abc1028a8bb8686dbb3749fcd2d18e8 is the first bad commit +commit a1f42e0c9abc1028a8bb8686dbb3749fcd2d18e8 +Author: xiaoqiang.zhao <zxq_yx_007@163.com> +Date: Mon Mar 7 15:05:44 2016 +0800 + + hw/arm: QOM'ify integratorcp.c + + * Drop the use of old SysBus init function and use instance_init + * Remove the empty 'icp_pic_class_init' from Typeinfo + + Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + +:040000 040000 b73418ea3fb69ed72438776e78786456fe4c414c b483e8579037fdae7d136b2f4ada3147bdde92f1 M hw + +Upon closer inspection, I discovered that for some reason s->memsz in integratorcm_init() is zero. In the last good revision, this value was 128. As a temporary workaround, hardcoding it to this expected value fixes the problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1626207 b/results/classifier/gemma3:12b/device/1626207 new file mode 100644 index 000000000..567050e5f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1626207 @@ -0,0 +1,46 @@ + +-device usb-host failing with usbip_vudc-vhdi_hcd gadget + +I must admit that I do not know if this is a Qemu or a Kernel issue, but I try reporting here: + +When I try to forward a copy of my USB mouse that I made with the new virtual USB device controller in kernel 4.7 I get the following in my log: +[ +0.703256] usb 1-4: reset full-speed USB device number 3 using xhci_hcd +[ +1.020776] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855013] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.859052] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.857000] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.000141] usb 7-3: USB disconnect, device number 10 +[ +0.153056] usb 1-4: reset full-speed USB device number 3 using xhci_hcd +[ +0.703746] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855001] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855006] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.855005] usb usb7-port3: Cannot enable. Maybe the USB cable is bad? +[ +0.000009] usb usb7-port3: unable to enumerate USB device + +the commands I use for makeing the virtual device are(after making a copy of the report description of my real mouse in /root/usb/kingston_report_desc): + mkdir /sys/kernel/config/usb_gadget/winmouse + cd /sys/kernel/config/usb_gadget/winmouse + echo "0x047d" > idVendor + echo "0x1020" > idProduct + mkdir strings/0x409 + echo 2016 > strings/0x409/serialnumber + echo Kensington > strings/0x409/manufacturer + echo "Kensington Expert Mouse" > strings/0x409/product + mkdir configs/c.1 + mkdir configs/c.1/strings/0x409 + mkdir functions/hid.usb2 + echo 2 > functions/hid.usb2/protocol + echo 1 > functions/hid.usb2/subclass + echo 4 > functions/hid.usb2/report_length + cat /root/usb/kingston_report_desc > functions/hid.usb2/report_desc + echo 0xa0 > configs/c.1/bmAttributes + echo 100 > configs/c.1/MaxPower + + ln -s functions/hid.usb2 configs/c.1 + echo usbip-vudc.2 > UDC + + usbip attach -r localhost -d usbip-vudc.2 + +The virtual mouse then shows up as Bus7,Dev10 and I use the option -device usb-host,hostbus=7,hostaddr=10,id=hostdev6,bus=usb.0,port=2 in Qemu to attach it. + +This is Qemu 2.7.0 on kernel 4.7.4 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1628 b/results/classifier/gemma3:12b/device/1628 new file mode 100644 index 000000000..6dbe1f98a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1628 @@ -0,0 +1,131 @@ + +windows 10 display scale will cause an exception +Description of problem: +windows dispaly sacle 150% or higher, windows system will exception +Steps to reproduce: +1. windows dispaly sacle 150% +Additional information: +- code in: qemu/hw/display/qxl-render.c + +static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl, + QXLDataChunk *chunk, uint32_t group_id) +{ + uint32_t max_chunks = 32; + size_t offset = 0; + size_t bytes; + for (;;) { + bytes = MIN(size - offset, chunk->data_size); + memcpy(dest + offset, chunk->data, bytes); + offset += bytes; + if (offset == size) { + return; + } + chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id, + sizeof(QXLDataChunk) + chunk->data_size); + **// get next chunk, but the chunk size use current chunk's data size, not next chunk's data size!!!!** + **// if next chunk alloc size < current chunk's data size, there will be exception ** + + if (!chunk) { + return; + } + max_chunks--; + if (max_chunks == 0) { + return; + } + } +} + + + +- code in: qxl_wddm_dod/QXLDod.cpp exist next chunk alloc size < current chunk's data size + +NTSTATUS QxlDevice::SetPointerShape(_In_ CONST DXGKARG_SETPOINTERSHAPE* pSetPointerShape) +{ +..... + res = (Resource *)AllocMem(MSPACE_TYPE_VRAM, CURSOR_ALLOC_SIZE, TRUE); // here we all the first QXLDataChunk , and alloc_size = (CURSOR_ALLOC_SIZE - sizeof(Resource) - sizeof(InternalCursor)) = 8118 + +..... + for (; src != src_end; src += pSetPointerShape->Pitch) { + if (!PutBytesAlign(&chunk, &now, &end, src, line_size, PAGE_SIZE - PAGE_SIZE % line_size, NULL)) { // in this function ,we will alloc next QXLDataChunk + .......... + break; + } + } +} + +BOOLEAN QxlDevice::PutBytesAlign(QXLDataChunk **chunk_ptr, UINT8 **now_ptr, + UINT8 **end_ptr, UINT8 *src, int size, + size_t alloc_size, PLIST_ENTRY pDelayed) +{ + ..... + size_t maxAllocSize = BITS_BUF_MAX - BITS_BUF_MAX % size; + alloc_size = MIN(alloc_size, maxAllocSize); + void *ptr = AllocMem(MSPACE_TYPE_VRAM, alloc_size + sizeof(QXLDataChunk), bForced); *** //here will alloc next QXLDataChunk and alloc_size = (PAGE_SIZE - PAGE_SIZE % line_size) = 3876 **** +} + + +eg: +dispaly sacle 150% ，mouse size will bu change to 57* 55 ，rgba data size = 12540, we need three QXLDataChunk + +QXLDataChunk* first; +first->data_size = 8118; +first->prev_chunk = 0; +first->next_chunk=second; +first->data = [alloc_size(8118), data_size(8118)] + +QXLDataChunk* second; +second->data_size = 3876; +second->prev_chunk = first; +second->next_chunk=third; +second->data = [alloc_size(3876), data_size(3876)] + +QXLDataChunk* third; +third->data_size = 546; +third->prev_chunk =second; +third->next_chunk=0; +third->data = [alloc_size(3876), data_size(546)] + + +chunk = first; +qxl_phys2virt(qxl, second, group_id, sizeof(QXLDataChunk) + 8118) + + +this size [sizeof(QXLDataChunk) + 8118] > second QXLDataChunk's alloc size , will cause qxl_get_check_slot_offset check fail + + +for second QXLDataChunk, we actual alloc size is (sizeof(QXLDataChunk) + 3876), but we assign (8118 + sizeof(QXLDataChunk)) will cause an exception + + +suggest code : + +static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl, + QXLDataChunk *chunk, uint32_t group_id) +{ + uint32_t max_chunks = 32; + size_t offset = 0; + size_t bytes; + QXLPHYSICAL next_chunk_phys = 0; + for (;;) { + bytes = MIN(size - offset, chunk->data_size); + memcpy(dest + offset, chunk->data, bytes); + offset += bytes; + if (offset == size) { + return; + } + next_chunk_phys = chunk->next_chunk; + chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id, + sizeof(QXLDataChunk)); // fist time, only get the next chunk's data size; + if (!chunk) { + return; + } + chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id, + sizeof(QXLDataChunk) + chunk->data_size); // second time, check data size and get data; + if (!chunk) { + return; + } + max_chunks--; + if (max_chunks == 0) { + return; + } + } +} diff --git a/results/classifier/gemma3:12b/device/1630 b/results/classifier/gemma3:12b/device/1630 new file mode 100644 index 000000000..a01cd5fb4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1630 @@ -0,0 +1,201 @@ + +[8.0.0] qemu breaks mac os vm (passed through sata controller) +Description of problem: +I have a mac os montery vm which is not able to boot after upgrading from qemu 7.2.1 to qemu 8.0.0.\ +Mac os bootloader (opencore) logs do not show anything useful, nothing useful also in libvirt logs.\ +Apple screen hangs at "still waiting for root device" with the prohibition symbol.\ +This should point that mac os is not able to find the disk to boot from.\ +The bootloader sees the disk with its partitions.\ +I'm passing through a sata controller with the boot disk attached, together with a usb controller, builtin audio and a gpu.\ +Changing machine type (q35) to older versions change nothing.\ +Downgrading to 7.2.1 and no issue. + +Maybe related to some acpi changes? +Additional information: +This is the libvirt xml I'm using: +``` +<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <name>Montereytest</name> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static'>8</vcpu> + <iothreads>2</iothreads> + <iothreadids> + <iothread id='1'/> + <iothread id='2'/> + </iothreadids> + <cputune> + <vcpupin vcpu='0' cpuset='1'/> + <vcpupin vcpu='1' cpuset='2'/> + <vcpupin vcpu='2' cpuset='3'/> + <vcpupin vcpu='3' cpuset='4'/> + <vcpupin vcpu='4' cpuset='5'/> + <vcpupin vcpu='5' cpuset='6'/> + <vcpupin vcpu='6' cpuset='7'/> + <vcpupin vcpu='7' cpuset='9'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-q35-7.2'>hvm</type> + <loader readonly='yes' type='pflash'>/opt/macos/OVMF_CODE_TEST.fd</loader> + <nvram>/opt/macos/OVMF_VARS_TEST.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='1' dies='1' cores='4' threads='2'/> + </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>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x8'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x9'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0xc'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='c8:2a:14:55:1a:b2'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='c8:2a:14:32:2c:ff'/> + <source bridge='br1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='keyboard' bus='ps2'/> + <input type='mouse' bus='ps2'/> + <audio id='1' type='none'/> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </source> + <rom file='/opt/gpu-bios/6900xt.rom'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/> + </source> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x046d'/> + <product id='0x0892'/> + </source> + <address type='usb' bus='0' port='2'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x148f'/> + <product id='0x3070'/> + </source> + <address type='usb' bus='0' port='1'/> + </hostdev> + <watchdog model='itco' action='reset'/> + <memballoon model='none'/> + </devices> + <qemu:commandline> + <qemu:arg value='-smbios'/> + <qemu:arg value='type=2'/> + <qemu:arg value='-global'/> + <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-speed=8'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-width=16'/> + <qemu:arg value='-cpu'/> + <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/> + </qemu:commandline> +</domain> +``` + +06:00.0/1 --> gpu\ +00:1b.0 --> audio\ +0c:00.0 --> sata controller\ +84:00.0 --> usb controller\ +0x046d 0x0892 --> usb webcam\ +0x148f 0x3070 --> usb wifi + + + +[] diff --git a/results/classifier/gemma3:12b/device/1630527 b/results/classifier/gemma3:12b/device/1630527 new file mode 100644 index 000000000..4f2fdd3d6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1630527 @@ -0,0 +1,12 @@ + +qemu/hw/i386/amd_iommu.c:188: possible bad shift ? + +qemu/hw/i386/amd_iommu.c:188]: (error) Shifting 32-bit value by 64 bits is undefined behaviour + +Source code is + + uint64_t mask = ((1 << length) - 1) << bitpos; + +Maybe better code + + uint64_t mask = ((1ULL << length) - 1) << bitpos; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1637511 b/results/classifier/gemma3:12b/device/1637511 new file mode 100644 index 000000000..072f5f92d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1637511 @@ -0,0 +1,22 @@ + +Armitage crashes KVM guest with Kali2016.2 for QXL video + +I recently got a strange bug which seems to be related to qemu-kvm and QXL. I came here via the hints of the KVM web-site for KVM/qemu bug tracking. But, I am not sure whether this is the right bug-tracker at all. Please advise me if I placed the report wrongly. + +I installed Kali2016.2 as a KVM guest on a Opensuse Leap 42.1 host (fully updated). The KVM guest machine was configured to use a spice display and QXL video. Everything OK with the installation with the exception of one major application with a Java interface - Armitage. + +Armitage is correctly configured and starts (with some minor Java errors) and opens its interface (msf console, target window etc.) Trying to open the 2 specific menu points "Hosts" or "Attack" in the menu bar leads to something very strange: The screen flickers, then the whole login session is stopped and a standard login window opens. This happens independently of the setting for the type of Armitage target window (graphical or table like) + +Why do I report this bug here? +Because it happens with the QXL graphical video interface ONLY - not with video=vga or vmvga ! Neither does the bug occur when Armitage is started in a ssh (-X) session from the host. + +So, it is closely related to qemu-kvm AND QXL and the Java interaction with both. + +I really wonder what in the world can make 2 specific menu points of a Java application crash a KVM guest and restart a login shell in Kali only when QXL is used? + +qemu-kvm version : 2.3.1 +Kernel version of OS LEAP 42.1: Linux 4.1.31-30-default + +I have described the bug also to the Kali people - see https://bugs.kali.org/view.php?id=3698 + +Please inform me what further data are required - if this is relevant in this bug-tracker at all. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1637974 b/results/classifier/gemma3:12b/device/1637974 new file mode 100644 index 000000000..f13403fb6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1637974 @@ -0,0 +1,49 @@ + +dead code in pl080 functions + +pl080 is arm dma controller virtual device. +source code path: hw/dma/pl080.c +I find there are two same dead code in pl080_read and pl080_write, +Here's the code, comments are my opinion: +========================= +240 static uint64_t pl080_read(void *opaque, hwaddr offset, +241 unsigned size) +242 { +243 PL080State *s = (PL080State *)opaque; +244 uint32_t i; +245 uint32_t mask; +246 +247 if (offset >= 0xfe0 && offset < 0x1000) { +248 if (s->nchannels == 8) { +249 return pl080_id[(offset - 0xfe0) >> 2]; +250 } else { +251 return pl081_id[(offset - 0xfe0) >> 2]; +252 } +253 } +254 if (offset >= 0x100 && offset < 0x200) { //// here offset is limited in 0x100~0x200 +255 i = (offset & 0xe0) >> 5; +256 if (i >= s->nchannels) +257 goto bad_offset; +258 switch (offset >> 2) { //// then here, offset>>2 is in range 64~128 +259 case 0: /* SrcAddr */ //// while the switch case is 0,1,2,3,4, +260 return s->chan[i].src; //// so, NONE of the switch case would be selected ! +261 case 1: /* DestAddr */ //// this switch is A DEAD CODE, it is contradictory with if. +262 return s->chan[i].dest; +263 case 2: /* LLI */ +264 return s->chan[i].lli; +265 case 3: /* Control */ +266 return s->chan[i].ctrl; +267 case 4: /* Configuration */ +268 return s->chan[i].conf; +269 default: +270 goto bad_offset; +271 } +272 } + ..................................... +============================================= + +I guess, switch statement should like this : +switch((offset-0x100)>>2) +{ +... +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1639791 b/results/classifier/gemma3:12b/device/1639791 new file mode 100644 index 000000000..25bb8b59b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1639983 b/results/classifier/gemma3:12b/device/1639983 new file mode 100644 index 000000000..793c75774 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1639983 @@ -0,0 +1,22 @@ + +e1000 EEPROM have bad checksum + +I am using qemu-system-i386 to emulate FreeDOS with e1000 nic card. + +I am using Intel PRODOS v.19.0 (latest version with E1000ODI.COM file). +E1000ODI.COM v.5.07 (140116) + +http://pclosmag.com/html/issues/201208/page11.html +Suggest that v.4.75 (120212) was/is working. +Oldest PRODOS available version seems now 18.5 (June 2013) which I have not tested yet. + +When running it, it detect: Slot 18, IRQ 11, Port C000. + +But complains: +EEPROM checksum was incorrect. + +Contact your services network supplier for a replacement. + +paul@paul89473:~$ qemu-system-i386 --version +QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu5), Copyright (c) 2003-2008 Fabrice Bellard +paul@paul89473:~$ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1640 b/results/classifier/gemma3:12b/device/1640 new file mode 100644 index 000000000..c13345f56 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1643537 b/results/classifier/gemma3:12b/device/1643537 new file mode 100644 index 000000000..895fef665 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1643537 @@ -0,0 +1,24 @@ + +target-ppc/int_helper.c: 2 * bad array index + +1. + +[qemu/target-ppc/int_helper.c:2575]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Source code is + + return reg->u16[8 - n]; + +and + +qemu/target-ppc/cpu.h: uint16_t u16[8]; + +but at least once, n is zero, for example line 2725 in the int_helper.c file: + + uint16_t sgnb = get_national_digit(b, 0); + +2. + +[qemu/target-ppc/int_helper.c:2584]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Duplicate \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1646610 b/results/classifier/gemma3:12b/device/1646610 new file mode 100644 index 000000000..5df7101e6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1646610 @@ -0,0 +1,71 @@ + +"Assertion `!r->req.sg' failed." during live migration with VirtIO + +We've hit this issue twice so far, but don't have an obvious repro yet. It's pretty rare for us to hit it but I'm still trying so I can get a core and backtrace. The guest was Windows running a constant workload. We were using VirtIO SCSI drivers in both cases. + +In both cases we hit the assert here: + +hw/scsi/scsi-generic.c: + +static void scsi_generic_save_request(QEMUFile *f, SCSIRequest *req) +{ + SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req); + + qemu_put_sbe32s(f, &r->buflen); + if (r->buflen && r->req.cmd.mode == SCSI_XFER_TO_DEV) { +*** assert(!r->req.sg); + qemu_put_buffer(f, r->buf, r->req.cmd.xfer); + } +} + +From code inspection, it seems that this will always happen if scsi_req_enqueue_internal in hw/scsi/scsi-bus.c is ever invoked. + +static void scsi_req_enqueue_internal(SCSIRequest *req) +{ + assert(!req->enqueued); + scsi_req_ref(req); + if (req->bus->info->get_sg_list) { + req->sg = req->bus->info->get_sg_list(req); + } else { + req->sg = NULL; + } + req->enqueued = true; + QTAILQ_INSERT_TAIL(&req->dev->requests, req, next); +} + +req->bus->info->get_sg_list will return &req->qsgl for a virtio-scsi bus since it's a method stored on the SCSIBusInfo struct. I didn't see anything that would clear the req->sg if scsi_req_enqueue_internal is called at least once. + +I think this can only happen if scsi_dma_restart_bh in hw/scsi/scsi-bus.c is called. The only other location I see scsi_req_enqueue_internal is on the load side for the destination of a migration. + +static void scsi_dma_restart_bh(void *opaque) +{ + SCSIDevice *s = opaque; + SCSIRequest *req, *next; + + qemu_bh_delete(s->bh); + s->bh = NULL; + + QTAILQ_FOREACH_SAFE(req, &s->requests, next, next) { + scsi_req_ref(req); + if (req->retry) { + req->retry = false; + switch (req->cmd.mode) { + case SCSI_XFER_FROM_DEV: + case SCSI_XFER_TO_DEV: + scsi_req_continue(req); + break; + case SCSI_XFER_NONE: + scsi_req_dequeue(req); + scsi_req_enqueue(req); // *** this calls scsi_req_enqueue_internal + break; + } + } + scsi_req_unref(req); + } +} + +Finally when put_scsi_requests is called for migration, it seems like it will call both virtio_scsi_save_request (from bus->info->save_request) and scsi_generic_save_request (from req->ops->save_request) and trigger the assert. + +I searched for a bit, but didn't find anyone else reporting this. Has anyone else seen this? It seems to me like that assert should check that the sg list is empty instead of checking that it exists. Is this an appropriate assessment? Assuming I find a repro, I'll try to test this solution. + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1648726 b/results/classifier/gemma3:12b/device/1648726 new file mode 100644 index 000000000..1ff27d8dc --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/165 b/results/classifier/gemma3:12b/device/165 new file mode 100644 index 000000000..b88370d5a --- /dev/null +++ b/results/classifier/gemma3:12b/device/165 @@ -0,0 +1,2 @@ + +No evdev mouse passthrough with virtio-vga or kvm diff --git a/results/classifier/gemma3:12b/device/1651 b/results/classifier/gemma3:12b/device/1651 new file mode 100644 index 000000000..48180d22c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1651 @@ -0,0 +1,2 @@ + +bcm2835 timer jumps to max delay diff --git a/results/classifier/gemma3:12b/device/1653384 b/results/classifier/gemma3:12b/device/1653384 new file mode 100644 index 000000000..83d43f639 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1653384 @@ -0,0 +1,60 @@ + +Assertion failed with USB pass through with XHCI controller + +Starting qemu 2.8.0 with XHCI controller and host device passed through results in an assertion failure: + +qemu-system-x86_64: hw/usb/core.c:623: usb_packet_cleanup: Assertion `!usb_packet_is_inflight(p)' failed. + +Can be reproduced with the following command (passing through a Lenovo keyboard): + +qemu-system-x86_64 -usb -device nec-usb-xhci,id=usb -device usb-host,vendorid=0x04b3,productid=0x3025,id=hostdev0,bus=usb.0,port=1 + +If nec-usb-xhci is changed to usb-ehci, qemu tries to boot without assertion failures. + + +Can be reproduced with the latest master (commit dbe2b65) and v2.8.0. + +Bisected the issue to following commit: +first bad commit: [94b037f2a451b3dc855f9f2c346e5049a361bd55] xhci: use linked list for transfers + + +Backtrace from commit dbe2b65: + +#0 0x00007f2eb4657227 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 + resultvar = 0 + pid = 3453 + selftid = 3453 +#1 0x00007f2eb465867a in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, sa_mask = {__val = {140734740550528, 93876690035339, + 140734740550624, 48833659808, 0, 0, 0, 21474836480, 140734740550792, 139838573009553, 140734740550560, 139838573043008, + 139838573024160, 93876666665872, 139838702616576, 139838573024160}}, sa_flags = 1528954938, + sa_restorer = 0x55615b2202c0 <__PRETTY_FUNCTION__.38612>} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007f2eb46502cd in __assert_fail_base (fmt=0x7f2eb47893a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55615b22003a "!usb_packet_is_inflight(p)", file=file@entry=0x55615b21fdf0 "hw/usb/core.c", line=line@entry=619, + function=function@entry=0x55615b2202c0 <__PRETTY_FUNCTION__.38612> "usb_packet_cleanup") at assert.c:92 + str = 0x55615cfdf510 "" + total = 4096 +#3 0x00007f2eb4650382 in __GI___assert_fail (assertion=0x55615b22003a "!usb_packet_is_inflight(p)", file=0x55615b21fdf0 "hw/usb/core.c", + line=619, function=0x55615b2202c0 <__PRETTY_FUNCTION__.38612> "usb_packet_cleanup") at assert.c:101 +No locals. +#4 0x000055615afc385e in usb_packet_cleanup () +No symbol table info available. +#5 0x000055615afda555 in xhci_ep_free_xfer () +No symbol table info available. +#6 0x000055615afdc156 in xhci_kick_epctx () +No symbol table info available. +#7 0x000055615afda099 in xhci_ep_kick_timer () +No symbol table info available. +#8 0x000055615b08ceee in timerlist_run_timers () +No symbol table info available. +#9 0x000055615b08cf36 in qemu_clock_run_timers () +No symbol table info available. +#10 0x000055615b08d2df in qemu_clock_run_all_timers () +No symbol table info available. +#11 0x000055615b08be40 in main_loop_wait () +No symbol table info available. +#12 0x000055615ae3870f in main_loop () +No symbol table info available. +#13 0x000055615ae4027b in main () \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1657 b/results/classifier/gemma3:12b/device/1657 new file mode 100644 index 000000000..601845607 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1657 @@ -0,0 +1,34 @@ + +Unable to use ide hard drive when using xlnx-zcu102 board +Description of problem: +I have only recently started using qemu and am reading content related to ahci. When I started QEMU using the above command line (I did not specify the Linux kernel because I only wanted to see which devices were initialized on the motherboard), I found the following devices in the device tree: + ``` +dev: sysbus-ahci, id "" + +gpio-out "sysbus-irq" 1 + +num-ports = 2 (0x2) + +mmio 00000000fd0c0000/0000000000001000 + +bus: ide.1 + +type IDE + +bus: ide.0 + +type IDE + ``` + +I think this is similar to the ICH9 ahci device, so I tried to mount an IDE hard drive（using command line：-drive file=./testide.img）but failed. QEMU shows + ``` +qemu-system-aarch64: -drive file=./ testide.img: machine type does not support if=ide,bus=0,unit=0 + ``` +So if the ide bus generated by sysbus ahci cannot mount a hard drive, what device should it mount? +It will be grateful if anyone can answer this question. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1661815 b/results/classifier/gemma3:12b/device/1661815 new file mode 100644 index 000000000..77df83f44 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1661815 @@ -0,0 +1,27 @@ + +Stack address is returned from function translate_one + +The vulnerable version is qemu-2.8.0, and the vulnerable function is in "target-s390x/translate.c". + +The code snippet is as following. + +static ExitStatus translate_one(CPUS390XState *env, DisasContext *s) +{ + const DisasInsn *insn; + ExitStatus ret = NO_EXIT; + DisasFields f; + ... + s->fields = &f; + ... + s->pc = s->next_pc; + return ret; +} + +A stack address, i.e. the address of local variable "f" is returned from current function through the output parameter "s->fields" as a side effect. + +This issue is one kind of undefined behaviors, according the C Standard, 6.2.4 [ISO/IEC 9899:2011] (https://www.securecoding.cert.org/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations) + +This dangerous defect may lead to an exploitable vulnerability. +We suggest sanitizing "s->fields" as null before return. + +Note that this issue is reported by shqking and Zhenwei Zou together. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1668556 b/results/classifier/gemma3:12b/device/1668556 new file mode 100644 index 000000000..bd1f8baf6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1671677 b/results/classifier/gemma3:12b/device/1671677 new file mode 100644 index 000000000..0144f6903 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1671677 @@ -0,0 +1,23 @@ + +vfio-pci passthrough issue after resume from suspend + + +I'm running into a weird issue with the vfio-pci driver through qemu + +I use it on a laptop and I passthrough an external GPU connected via PCI express. In general this works well, however if the laptop has *ever* suspended since its last boot, then the windows guest reports an error 43 on the card and I get no output on the monitor that it is connected to. This is really weird to me since it works fine if I boot the latop from power-off, and hotplug the card. It's only if the laptop has ever suspended since it's last boot that I see this issue. Even if it was suspended before the card was ever hotplugged. + +In other words: +laptop off -> boot -> hotplug GPU : works great +laptop off -> boot -> do stuff (GPU *NOT* connected) -> sleep -> resume -> hotplug GPU: problem +laptop off -> boot -> hotplug GPU -> unplug GPU -> hotplug GPU : works great +laptop off -> boot -> hotplug GPU -> unplug GPU -> sleep -> resume -> hotplug GPU: problem + +Weird stuff... + +I'm honestly not sure that vfio-pci/qemu is to blame here since there are so many moving parts, but im not really sure where else to report this to + +What I have tried is using the sysfs interface to remove/rescan/poweroff/etc the PCI devices in questions (graphics card and it's HDMI audio) and this also does help. + +QEMU version: 2.6.1 + +Please let me know what other information I can provide \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1673722 b/results/classifier/gemma3:12b/device/1673722 new file mode 100644 index 000000000..097a5c7dd --- /dev/null +++ b/results/classifier/gemma3:12b/device/1673722 @@ -0,0 +1,14 @@ + +Reading register at offset. It is not fully implemented warning make VM impossible to use + +Hi, + +Since this commit: +https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 + +We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +e1000: Reading register at offset: 0x00002410. It is not fully implemented. + +User got so much of this warning that they can't use the VM. + +Thanks for the help \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1677492 b/results/classifier/gemma3:12b/device/1677492 new file mode 100644 index 000000000..3b2ddbe18 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1678466 b/results/classifier/gemma3:12b/device/1678466 new file mode 100644 index 000000000..e59da9335 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1679126 b/results/classifier/gemma3:12b/device/1679126 new file mode 100644 index 000000000..6bacb2ed6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/168 b/results/classifier/gemma3:12b/device/168 new file mode 100644 index 000000000..0d89d65f5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/168 @@ -0,0 +1,2 @@ + +ivshmem PCI device exposes wrong endianness on ppc64le diff --git a/results/classifier/gemma3:12b/device/1681398 b/results/classifier/gemma3:12b/device/1681398 new file mode 100644 index 000000000..1f1a714c0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1681398 @@ -0,0 +1,11 @@ + +hw/core: segmentation fault + +Reproducer: + $i386-softmmu/qemu-system-i386 -S -machine isapc,accel=tcg -device amd-iommu +Segmentation fault (core dumped) + +Partial bt: +#0 bus_add_child (child=0x555556d4e520, bus=0x0) at hw/core/qdev.c:88 +#1 qdev_set_parent_bus (dev=0x555556d4e520, bus=bus@entry=0x0) +at hw/core/qdev.c:119 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1681404 b/results/classifier/gemma3:12b/device/1681404 new file mode 100644 index 000000000..f03da6610 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1681404 @@ -0,0 +1,9 @@ + +hw/ppc: Aborted (core dumped) + +Reproducable: +$ ./ppc64-softmmu/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge + + +qemu/hw/ppc/spapr_pci.c:1567:spapr_phb_realize: Object 0x55bda99744a0 is not an instance of type spapr-machine +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1681439 b/results/classifier/gemma3:12b/device/1681439 new file mode 100644 index 000000000..64123f5d2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1681439 @@ -0,0 +1,36 @@ + +dma_blk_cb leaks memory map handles on misaligned IO + +Since upgrading to QEMU 2.8.0, my Windows 7 64-bit virtual machines +started crashing due to the assertion quoted in the summary failing. +The assertion in question was added by commit 9972354856 ("block: add +BDS field to count in-flight requests"). My tests show that setting +discard=unmap is needed to reproduce the issue. Speaking of +reproduction, it is a bit flaky, because I have been unable to come up +with specific instructions that would allow the issue to be triggered +outside of my environment, but I do have a semi-sane way of testing that +appears to depend on a specific initial state of data on the underlying +storage volume, actions taken within the VM and waiting for about 20 +minutes. + +Here is the shortest QEMU command line that I managed to reproduce the +bug with: + + qemu-system-x86_64 \ + -machine pc-i440fx-2.7,accel=kvm \ + -m 3072 \ + -drive file=/dev/lvm/qemu,format=raw,if=ide,discard=unmap \ + -netdev tap,id=hostnet0,ifname=tap0,script=no,downscript=no,vhost=on \ + -device virtio-net-pci,netdev=hostnet0 \ + -vnc :0 + +The underlying storage (/dev/lvm/qemu) is a thin LVM snapshot. + +QEMU was compiled using: + + ./configure --python=/usr/bin/python2.7 --target-list=x86_64-softmmu + make -j3 + +My virtualization environment is not really a critical one and +reproduction is not that much of a hassle, so if you need me to gather +further diagnostic information or test patches, I will be happy to help. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1685242 b/results/classifier/gemma3:12b/device/1685242 new file mode 100644 index 000000000..9c98bceb6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1685242 @@ -0,0 +1,21 @@ + +ovmf hangs at efi with virtio-net memory hotplug + +with qemu 2.9 it hangs at the efi stage when memory-hotplug is enabled and it has a virtio-net devices + +the ovmf images where compiled from https://github.com/tianocore/edk2 (current master) + +reproducer: + +qemu-system-x86_64 -drive 'if=pflash,unit=0,format=raw,readonly,file=./OVMF_CODE.fd' -drive 'if=pflash,unit=1,format=raw,file=./my_OVMF_VARS.fd' -smp 1 -vga std -netdev 'type=tap,id=mynet' -device 'virtio-net-pci,netdev=mynet' -display sdl -nodefaults -m 'size=1G,slots=256,maxmem=1024G' + +interestingly, it works when you do the following: + +- omit the virtio-net-pci device +- use seabios +- use less maxmem, e.g. 512G + +qemu was compiled from source (v2.9.0) with following options: + +./configure --target-list=x86_64-softmmu --disable-xen --enable-gnutls --enable-sdl --enable-linux-aio --enable-rbd --enable-libiscsi --disable-smartcard --audio-drv-list="alsa" --enable +-spice --enable-usb-redir --enable-glusterfs --enable-libusb --disable-gtk --enable-xfsctl --enable-numa --disable-strip --enable-jemalloc --enable-virtfs --disable-libnfs --disable-fdt --disable-guest-agent --disable-guest-agent-msi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1685526 b/results/classifier/gemma3:12b/device/1685526 new file mode 100644 index 000000000..c7db2cb0f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1685526 @@ -0,0 +1,4 @@ + +UEFI firmware can't write to "fake" FAT hard disk + +Using the Tianocore OVMF UEFI firmware, a UEFI application cannot write to the emulated fat disk (-hda fat:rw:path/here). A file will get created or written, but will be corrupted. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1687309 b/results/classifier/gemma3:12b/device/1687309 new file mode 100644 index 000000000..aca171f76 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1687309 @@ -0,0 +1,156 @@ + +Assertion !usb_packet_is_inflight(p) fails in OHCI + +I'm trying to get a USB web camera working in Qemu & Raspbian. USB works and V4L shows device info correctly and capturing frames from the camera works sometimes, but mostly it crashes with error message: + +qemu-system-arm: hw/usb/core.c:558: usb_packet_setup: Assertion `!usb_packet_is_inflight(p)' failed. + +This looks similar to the previous bug which also caused a crash on the same kind of assertion but the culprit was XHCI: https://bugs.launchpad.net/qemu/+bug/1653384 + + +== Versions == + +QEMU emulator version 2.9.50 (v2.9.0-303-g81b2d5c-dirty), +configured with +./configure --target-list=arm-softmmu,arm-linux-user,armeb-linux-user --enable-libusb --enable-libssh2 --enable-debug + +libusb: 1.0.21 + +Guest: 2017-04-10-raspbian-jessie-lite.img with kernel 4.4.34 for Raspbian on Qemu + +Command: /usr/local/bin/qemu-system-arm -kernel qemu-rpi-kernel/kernel-qemu-4.4.34-v4lm-jessie -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/sda2 panic=1" -drive format=raw,file=2017-04-10-raspbian-jessie-lite.img -usb -usbdevice host:046d:0928 -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 + +Web camera is an old Logitech QuickCam Express Etch2 (046d:0928). It works otherwise without problems. + + +== GDB Backtrace == + +qemu-system-arm: hw/usb/core.c:558: usb_packet_setup: Assertion `!usb_packet_is_inflight(p)' failed. + +Thread 1 "qemu-system-arm" received signal SIGABRT, Aborted. +0x00007fffdea6f428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +54 ../sysdeps/unix/sysv/linux/raise.c: Tiedostoa tai hakemistoa ei ole. +(gdb) bt full +#0 0x00007fffdea6f428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 + resultvar = 0 + pid = 16526 + selftid = 16526 +#1 0x00007fffdea7102a in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, sa_mask = {__val = {140737488345776, + 140737488351076, 140737488345856, 48702688480, 140737352876032, 93825001457954, 558, 93825001458576, 0, 0, + 140736929192332, 140736930289240, 140736930302896, 260615966, 140736930289240, 93825001457954}}, + sa_flags = -135479296, sa_restorer = 0x555555e20922} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007fffdea67bd7 in __assert_fail_base (fmt=<optimized out>, + assertion=assertion@entry=0x555555e20922 "!usb_packet_is_inflight(p)", + file=file@entry=0x555555e20686 "hw/usb/core.c", line=line@entry=558, + function=function@entry=0x555555e20b90 <__PRETTY_FUNCTION__.27044> "usb_packet_setup") at assert.c:92 + str = 0x5555573e0800 "" + total = 4096 +#3 0x00007fffdea67c82 in __GI___assert_fail (assertion=0x555555e20922 "!usb_packet_is_inflight(p)", + file=0x555555e20686 "hw/usb/core.c", line=558, + function=0x555555e20b90 <__PRETTY_FUNCTION__.27044> "usb_packet_setup") at assert.c:101 +No locals. +#4 0x0000555555b4015a in usb_packet_setup (p=0x555556e81bc8, pid=105, ep=0x55555733e180, stream=0, id=260615936, + short_not_ok=false, int_req=false) at hw/usb/core.c:558 + __PRETTY_FUNCTION__ = "usb_packet_setup" +#5 0x0000555555b4f2ee in ohci_service_iso_td (ohci=0x555556e814c0, ed=0x7fffffffdda0, completion=0) + at hw/usb/hcd-ohci.c:852 + int_req = false + dir = 2 + len = 1023 + str = 0x555555e233cf "in" + pid = 105 + ret = -8788 + i = -8912 + dev = 0x55555733d070 + ep = 0x55555733e180 + iso_td = {flags = 4039218540, bp = 251170816, next = 260615872, be = 251173880, offset = {59386, 0, 6, 0, 53328, + 53376, 0, 0}} + addr = 260615936 + starting_frame = 38252 + relative_frame_number = 0 + frame_count = 0 + start_offset = 59386 + next_offset = 0 + end_offset = 0 + start_addr = 251172858 + end_addr = 251173880 +#6 0x0000555555b5055c in ohci_service_ed_list (ohci=0x555556e814c0, head=260608080, completion=0) + at hw/usb/hcd-ohci.c:1239 + ed = {flags = 67080322, tail = 260614272, head = 260615936, next = 0} + next_ed = 0 + cur = 260608080 + active = 1 + link_cnt = 1 +#7 0x0000555555b50857 in ohci_frame_boundary (opaque=0x555556e814c0) at hw/usb/hcd-ohci.c:1304 + n = 12 + ohci = 0x555556e814c0 + hcca = {intr = {260608080 <repeats 32 times>}, frame = 38252, pad = 0, done = 0} +#8 0x0000555555d12050 in timerlist_run_timers (timer_list=0x555556939600) at util/qemu-timer.c:536 + ts = 0x555556ebc9b0 + current_time = 224991592167 + progress = false + cb = 0x555555b50778 <ohci_frame_boundary> + opaque = 0x555556e814c0 +#9 0x0000555555d1209c in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at util/qemu-timer.c:547 +No locals. +#10 0x0000555555d1244e in qemu_clock_run_all_timers () at util/qemu-timer.c:662 + progress = false + type = QEMU_CLOCK_VIRTUAL +#11 0x0000555555d12bf9 in main_loop_wait (nonblocking=0) at util/main-loop.c:525 + ret = 0 + timeout = 499 + timeout_ns = 977642 +#12 0x0000555555969440 in main_loop () at vl.c:1899 +No locals. +#13 0x0000555555971229 in main (argc=21, argv=0x7fffffffe358, envp=0x7fffffffe408) at vl.c:4717 + i = 0 + snapshot = 0 + linux_boot = 1 + initrd_filename = 0x0 + kernel_filename = 0x5555568d78c0 "qemu-rpi-kernel/kernel-qemu-4.4.34-v4lm-jessie" + kernel_cmdline = 0x5555568d8c80 "root=/dev/sda2 panic=1 " + boot_order = 0x0 + boot_once = 0x0 + ds = 0x55555718f750 + cyls = 0 + heads = 0 + secs = 0 + translation = 0 + opts = 0x0 + machine_opts = 0x5555568d8b20 + hda_opts = 0x0 + icount_opts = 0x0 + accel_opts = 0x0 + olist = 0x55555629fc80 <qemu_machine_opts> + optind = 21 + optarg = 0x7fffffffe780 "user,hostfwd=tcp::2222-:22" + loadvm = 0x0 + machine_class = 0x5555568eff50 + cpu_model = 0x7fffffffe6c2 "arm1176" + vga_model = 0x555555d8d8c4 "std" + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = 0x0 + incoming = 0x0 + defconfig = true + userconfig = true + nographic = false + display_type = DT_GTK + display_remote = 0 + log_mask = 0x0 + log_file = 0x0 + trace_file = 0x0 + maxram_size = 268435456 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7fffffffe140} + __func__ = "main" + + +(P.S. Tiedostoa tai hakemistoa ei ole = file or directory doesn't exist.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1689003 b/results/classifier/gemma3:12b/device/1689003 new file mode 100644 index 000000000..87b4d3e37 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1689003 @@ -0,0 +1,14 @@ + +USB passthrough should not fail if SET CONFIGURATION fails + +QEMU's USB passthrough was not working for my new smartphone. + +While analyzing the problem, I found out that a SET CONFIGURATION Request was NACKed by the USB device (probably because a SET CONFIGURATION request was already sent from the host to the device). + +So I wrote a simple program to fake a successful call to libusb_set_configuration and did an LD_PRELOAD on this program before starting qemu, and it worked. + +Looking at QEMU's code in host-libusb.c, I can see that QEMU does not try to claim the interface if its call to libusb_set_configuration fails. + +I think QEMU should try to claim the device anyway even if libusb_set_configuration fails. + +I did my tests against QEMU 2.6.2, but as I can see from the source code, this problem should happen on all versions. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1691 b/results/classifier/gemma3:12b/device/1691 new file mode 100644 index 000000000..d7f21336d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1691 @@ -0,0 +1,11 @@ + +QEMU's NVMe emulator behaving not standard compliant +Description of problem: +QEMU's NVMe emulator behaves slightly non-conformant to the standard. +For one, in the CAP.CSS register, bits 0, 6 and 7 are set. Bit 7 indicates that the NVMe Controller does not support any I/O Command Set, while bit 6 is set when the NVMe Controller supports one or more I/O Command Sets (see Figure 36 of the NVM Express® Base Specification, Revision 2.0c). This is obviously contradictory and only bit 6 (and 0) should be set. These bits are configured in hw/nvme/ctrl.c:8250. +The NVMe emulator also checks whether the values of CC.IOSQES and CC.IOCQES are within the allowed range when the controller is enabled by setting CC.EN to 1. However this check should not be performed yet, as the allowed range can only be discovered after the controller is enabled, by submitting the Identify Command. This command reports the valid range in the Identify Controller Data Structure, however it requires the controller to be enabled which in turn would, at least in the current version, require valid values in CC.IOSQES and CC.IOCQES. The NVMe emulator also uses the values configured in CC.IOSQES and IO.IOCQES for the Admin Queues which, from what I understand, should not be the case. Only the I/O Queues should use these values. These checks are done in hw/nvme/ctrl.c:7199f. In the same function the values are already used to initialize the controllers cqe_size and sqe_size which should also happen at a later time. +Steps to reproduce: +1. Start any virtual machine with a NVMe Controller attached. +2. Read the value of CAP.CSS (located in BAR0 of the PCIe NVMe Controller). This value will be contradictory. +3. Follow the initialization procedure as described in section 3.5.1 of the NVM Express® Base Specification, Revision 2.0c. Do not set the values of CC.IOSQES and CC.IOCQES. +4. The NVMe Controller will fail to enable when setting CC.EN to 1 by setting CC.CFS to 1 and reporting the respective trace event (pci_nvme_err_startfail_cqent_too_small and variations). diff --git a/results/classifier/gemma3:12b/device/1693050 b/results/classifier/gemma3:12b/device/1693050 new file mode 100644 index 000000000..218c32317 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1693050 @@ -0,0 +1,12 @@ + +xhci HCIVERSION register read emulation incorrectly handled + +We had an illumos user trying to run illumos in QEMU 2.9.0 with the qemu-xhci device enabled. Note, that while this was discovered against QEMU 2.9.0, from my current read of the HEAD, it is still present. The illumos bug at https://www.illumos.org/issues/8173 has additional information on how the user invoked qemu. While investigating the problem we found that the illumos driver was reading a version of 0x0000 when reading the HCIVERSION register from qemu. + +In the illumos driver we're performing a 16-bit read of the version register at offset 0x2. From looking around at other OSes, while Linux performs a 4 byte read at offset 0x0 and masks out the version, others that care about the version are doing a two byte read, though not all actually act on the version and some just discard the information. + +The user who hit this was able to enable tracing (note the tracing file is attached to the illumos bug linked previously) and we hit the unimplemented register read with offset 0x2 at http://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l2960. The xhci register specifies today that its allowed for users to do 1-4 byte reads; however, that it implements only four byte reads in its implementation (http://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3333). Hence why when we read the HCIVERSION register at offset 0x2, it isn't handled in xhci_cap_read() which then returns zeros. + +From digging into this, I think that we're coming into memory_region_dispatch_read() and then memory_region_dispatch_read1(). However, I don't see anything in either the general memory region logic or in the xhci_cap_read() function that would deal with adjusting the offset that we're reading at and then masking it off again. While the access_with_adjusted_size() attempts to deal with this, it never adjusts the hardware address that's passed in to be a multiple of the implementation defined offset that I can see. I suspect that the FIXME at line 582 (http://git.qemu.org/?p=qemu.git;a=blob;f=memory.c;hb=HEAD#l582) and the implementation in the xhci code is the crux of the problem. + +For the time being we're working around this in the illumos driver, but I wanted to point this out such that it might be helpful for other systems which are assuming that they can do the two byte read like on hardware. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1699628 b/results/classifier/gemma3:12b/device/1699628 new file mode 100644 index 000000000..5993d9da8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1699628 @@ -0,0 +1,18 @@ + +Direct Sound Audio does not stop + +The Bug: +DirectSound Audio does not stop because dsound_ctl_out does not end up calling IDirectSoundBuffer_Stop. This is due to a bug in dsound_get_status_out where the status flags returned from IDirectSoundBuffer_GetStatus are compared with DSERR_BUFFERLOST (an error code) rather than DSBSTATUS_BUFFERLOST (a status flag). The status is actually (DSBSTATUS_LOOPING | DSBSTATUS_PLAYING) and one of those flags happens to be set in the DSERR_BUFFERLOST value. As a result, dsound_get_status_out returns -1 and dsound_ctl_out exits before calling IDirectSoundBuffer_Stop. + +The Fix: +A simple replacement of DSERR_BUFFERLOST with DSBSTATUS_BUFFERLOST in dsound_get_status_out. +Should be: "if (*statusp & DSBSTATUS_BUFFERLOST) {" + +Version Information: +I was able to produce this bug in Qemu 2.9.0 and with the latest source pulled from git://git.qemu-project.org/qemu.git (commit 8dfaf23ae1). I was able to verify my suggested fix with the latest source. + +Guest OS: +Discovered running Minoca OS v0.4 (www.github.com/minoca/os). Images at https://www.minocacorp.com/download/nightlies/latest-x86. The Qemu test images I tried (http://wiki.qemu.org/Testing/System_Images) didn't have an easy sound setup (was looking for 'aplay' or similar). + +Qemu Command Line: +./qemu-system-x86_64.exe -m 512 -hda pc.img -smp 4 -usbdevice keyboard -device intel-hda -device hda-duplex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1701821 b/results/classifier/gemma3:12b/device/1701821 new file mode 100644 index 000000000..9096dfec5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1701821 @@ -0,0 +1,215 @@ + +floating-point operation bugs in qemu-sh4 + +When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions + asinf + cbrtf + copysignf + coshf + expm1f + fabsf + floor + fmaf + ldexpf + logbf + round + roundf + sinhf + tanhf + +How to reproduce: +- Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure asinf cbrtf copysignf coshf expm1f fabsf floor fma fmaf fmal ldexpf logbf round roundf sinhf tanhf +- Set environment variables for using qemu-sh4. +- cd testdir-math; mkdir build-sh4; cd build-sh4; ./configure --host=sh4-linux; make; make check + +Here are the failures (from the file testdir-math/build-sh4/gltests/test-suite.log): + + +FAIL: test-asinf +================ + +pc=0xf6751cdc sr=0x00000101 pr=0xf6758e86 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6751cd6 fpul=0x3f19999a +r0=0xf6751d88 r1=0x00000000 r2=0x00080000 r3=0x00000000 +r4=0xf6ffe21c r5=0xf6ffe230 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x3f19999a r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe230 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-asinf (exit status: 1) + +FAIL: test-cbrtf +================ + +pc=0x00400980 sr=0x00000001 pr=0x00400684 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x00400960 fpul=0x00000000 +r0=0x00400ae8 r1=0x00412070 r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00412064 r9=0x00400960 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe21c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-cbrtf (exit status: 1) + +FAIL: test-copysignf +==================== + +pc=0x004004ce sr=0x00000001 pr=0xf668d28c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004d2 fpul=0x00000000 +r0=0x80000000 r1=0x3f4ccccd r2=0xf6674284 r3=0xf6ffe2b0 +r4=0x00000001 r5=0xf6ffe2e4 r6=0xf6ffe2ec r7=0x00000000 +r8=0x00411088 r9=0x00411084 r10=0x00000000 r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0x004004d2) +Unhandled trap: 0x1a0 +FAIL test-copysignf (exit status: 1) + +FAIL: test-coshf +================ + +pc=0xf675223a sr=0x00000101 pr=0xf675223c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675231c fpul=0x3f19999a +r0=0x3f19999a r1=0x3f19999a r2=0x000000e0 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400734 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in delay slot (delayed_pc=0xf675231c) +Unhandled trap: 0x1a0 +FAIL test-coshf (exit status: 1) + +FAIL: test-expm1f +================= + +pc=0xf6757e08 sr=0x00000000 pr=0x004005ce fpscr=0x00081000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6757dfe fpul=0x00000000 +r0=0xf6757fb0 r1=0x00001000 r2=0x00080000 r3=0x3eb17218 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400514 r9=0x00000064 r10=0x00400514 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe234 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-expm1f (exit status: 1) + +FAIL: test-fabsf +================ + +pc=0x00400504 sr=0x00000001 pr=0xf660228c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004ec fpul=0x00000000 +r0=0x00400640 r1=0x00412074 r2=0x00000000 r3=0x00412078 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00080000 +r8=0x004007ac r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe260 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fabsf (exit status: 1) + +FAIL: test-floor2 +================= + +../../gltests/test-floor2.c:130: assertion 'correct_result_p (x, reference)' failed +qemu: uncaught target signal 6 (Aborted) - core dumped +FAIL test-floor2 (exit status: 134) + +FAIL: test-fmaf2 +================ + +pc=0xf675f5ac sr=0x00000101 pr=0xf675f5a6 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675f5a6 fpul=0x01800000 +r0=0xf675f4a4 r1=0x000065b0 r2=0x00080000 r3=0x3f800000 +r4=0x01800000 r5=0x00000000 r6=0xffffffe9 r7=0x7f800000 +r8=0xffffff6b r9=0xf6ffe1e4 r10=0xf6ffe1e8 r11=0xffffff6b +r12=0xf67ab008 r13=0xf6ffe1d8 r14=0x004004dc r15=0xf6ffe18c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fmaf2 (exit status: 1) + +FAIL: test-ldexpf +================= + +pc=0xf669efa0 sr=0x00000001 pr=0xf669ef9a fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf669ef9a fpul=0x3f99999a +r0=0xfffffdc6 r1=0x000c9d70 r2=0x00080000 r3=0x3f19999a +r4=0x0019999a r5=0x3f19999a r6=0xffffffe9 r7=0x7f800000 +r8=0x00000001 r9=0x0040041c r10=0xf6ffe23c r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe218 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-ldexpf (exit status: 1) + +FAIL: test-logbf +================ + +pc=0xf675842c sr=0x00000001 pr=0x00400664 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758422 fpul=0x00000000 +r0=0xf6758480 r1=0x00000000 r2=0x00080000 r3=0x00080000 +r4=0x00000000 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0xf6ffe24c r9=0x0040054c r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe244 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-logbf (exit status: 1) + +FAIL: test-round2 +================= + +FAIL test-round2 (exit status: 1) + +FAIL: test-roundf2 +================== + +FAIL test-roundf2 (exit status: 1) + +FAIL: test-sinhf +================ + +pc=0xf675581c sr=0x00000101 pr=0xf675a784 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6755858 fpul=0x3f19999a +r0=0xf6755930 r1=0x317fffff r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe238 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0xf6755858) +Unhandled trap: 0x1a0 +FAIL test-sinhf (exit status: 1) + +FAIL: test-tanhf +================ + +pc=0xf6758ca4 sr=0x00000100 pr=0x0040057c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758c9a fpul=0x3f19999a +r0=0xf6758d00 r1=0x00000000 r2=0x00080000 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe254 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-tanhf (exit status: 1) + + +I don't have access to sh4 hardware, so I cannot provide this as a comparison point. +But most of the test failures don't look like "merely" a wrong computation by glibc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1702621 b/results/classifier/gemma3:12b/device/1702621 new file mode 100644 index 000000000..d4915bb09 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1702621 @@ -0,0 +1,35 @@ + +colo: secondary vm crash during loadvm + +Following document 'COLO-FT.txt', I test colo feature on my hosts. It seems goes well. But after a while the secondary vm crash. The stack is as follows: +#0 0x00007f191456dc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007f1914571028 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x00007f1914566bf6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007f1914566ca2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +#5 0x0000564154a07cdb in qbus_reset_one (bus=0x564156760d10, opaque=0x0) at hw/core/qdev.c:319 +#6 0x0000564154a0d721 in qbus_walk_children (bus=0x564156760d10, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:68 +#7 0x0000564154a08b4d in qdev_walk_children (dev=0x56415675f2b0, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/qdev.c:617 +#8 0x0000564154a0d6e5 in qbus_walk_children (bus=0x564156594d30, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:59 +#9 0x0000564154a07df5 in qbus_reset_all (bus=0x564156594d30) at hw/core/qdev.c:336 +#10 0x0000564154a07e3a in qbus_reset_all_fn (opaque=0x564156594d30) at hw/core/qdev.c:342 +#11 0x0000564154a0e222 in qemu_devices_reset () at hw/core/reset.c:69 +#12 0x00005641548b3b47 in pc_machine_reset () at /vms/git/qemu/hw/i386/pc.c:2234 +#13 0x0000564154972ca7 in qemu_system_reset (report=false) at vl.c:1697 +#14 0x0000564154b9d007 in colo_process_incoming_thread (opaque=0x5641553c1280) at migration/colo.c:617 +#15 0x00007f1914907184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#16 0x00007f1914634bed in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +(gdb) frame 4 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +warning: Source file is more recent than executable. +311 assert(bus->irq_count[i] == 0); +(gdb) ^CQuit +(gdb) p bus->irq_count[i] +$1 = -1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1706058 b/results/classifier/gemma3:12b/device/1706058 new file mode 100644 index 000000000..f45431e76 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1706058 @@ -0,0 +1,27 @@ + +Windows VM crashes when restoring from file if balloon stats polling is enabled + +[Impact] + + * Windows VMs BSOD when restoring from QEMUfile or during live migration if the virtio balloon stats polling is enabled. + +[Test Case] + + * Install a Windows VM with virtio balloon drivers + * Start the VM and enable stats polling [1] + * Save the VM to savefile [2] + * Restore the VM [3] + * Enable stats polling [1] and VM will BSOD + +QMP examples: + [1] {"execute":"qom-set","arguments":{"path":"//machine/i440fx/pci.0/child[7]","property":"guest-stats-polling-interval","value":10}} + [2] {"execute": "migrate", "arguments": {"uri":"exec:gzip -c > /storage/cases/VM/savefiles/testVM3save.gz"}} + [3] {"execute":"migrate-incoming","arguments":{"uri":"exec:gzip -c -d /storage/cases/VM/savefiles/testVM3save.gz"}} + +[Other Info] + + * This has been fixed upstream with commit 4a1e48becab81020adfb74b22c76a595f2d02a01 + +[Regression Potential] + + * \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1708551 b/results/classifier/gemma3:12b/device/1708551 new file mode 100644 index 000000000..acf6b9421 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1709 b/results/classifier/gemma3:12b/device/1709 new file mode 100644 index 000000000..cad0f853a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1709 @@ -0,0 +1,37 @@ + +Qemu commit 7efd65423a cannot be built: Couldn't find file "symbols/ar" in include paths +Description of problem: +Hello. + +I try to build qemu based on commit 7efd65423a but it breaks in step 9035/10108, complaining about a missing "symbols/ar". + +The last time I get a full build was with commit fdd0df5340. + +Configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror` + +Here is the error log I got: + +``` +Running postconf script '/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/symlink-install-tree.py' +[9035/10108] Generating pc-bios/keymaps/ar with a custom command +FAILED: pc-bios/keymaps/ar +/home/fred/qemu-git/src/qemu/build-full/qemu-keymap -f pc-bios/keymaps/ar -l ar +xkbcommon: ERROR: Couldn't find file "symbols/ar" in include paths +xkbcommon: ERROR: 1 include paths searched: +xkbcommon: ERROR: /usr/share/X11/xkb +xkbcommon: ERROR: 3 include paths could not be added: +xkbcommon: ERROR: /home/fred/.config/xkb +xkbcommon: ERROR: /home/fred/.xkb +xkbcommon: ERROR: /etc/xkb +xkbcommon: ERROR: Abandoning symbols file "(unnamed)" +xkbcommon: ERROR: Failed to compile xkb_symbols +xkbcommon: ERROR: Failed to compile keymap +[9040/10108] Generating pc-bios/edk2-x...d (wrapped by meson to capture output) +ninja: build stopped: subcommand failed. +``` + +I'll try to do a bisect as soon as possible to see which commit break all. +Steps to reproduce: +1. Just grab commit 7efd65423a +2. Apply these configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror` +3. launch make and wait diff --git a/results/classifier/gemma3:12b/device/1713066 b/results/classifier/gemma3:12b/device/1713066 new file mode 100644 index 000000000..d3608fd2d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1713066 @@ -0,0 +1,20 @@ + +Incorrect handling of aarch64 ldp in some cases + +In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. + +Given the following instruction: +ldp x0, x1, [x0] + +This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. + +I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. + +I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. + +I've observed this on: +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard + +And checked I still get the same behaviour on: +QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) +Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1715007 b/results/classifier/gemma3:12b/device/1715007 new file mode 100644 index 000000000..f477bf2cf --- /dev/null +++ b/results/classifier/gemma3:12b/device/1715007 @@ -0,0 +1,17 @@ + +hw/block/onenand.c:520: dead code ? + +qemu/hw/block/onenand.c:520] -> [qemu/hw/block/onenand.c:521]: (warning) Opposite inner 'if' condition leads to a dead code block. + +Source code is + + for (b = 0; b < s->blocks; b ++) { + if (b >= s->blocks) { + s->status |= ONEN_ERR_CMD; + break; + } + +I am not sure if the if condition can be merely deleted, or something more +complex needs to be implemented. + +Recent qemu trunk. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1716 b/results/classifier/gemma3:12b/device/1716 new file mode 100644 index 000000000..92be1f5d6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1716 @@ -0,0 +1,10 @@ + +Cannot raise low memory using max-ram-below-4g on current i440fx +Description of problem: +We have a use case where we have a virtual machine with at least 8 Gb of RAM and at least 3.5Gb of it in the low memory. However, I could not achieve it this far with QEMU, only on the deprecated i440fx 1.7 architecture. The size of lowmem is never greater than 3 Gb, except if I assign memory to the vm between 3 Gb and 3.5 Gb. If I go even a slightly above 3.5 Gb then it falls back to 3 Gb. + +I did some research and I found the source file hw/i386/pc_piix.c. There is a piece of code which is responsible for setting the low memory at the beginning of function pc_init1(). It seems that the problem lies in the property `gigabyt_align` of all i440fx architectures newer than 1.7. The comment which explains this piece of code does not mention at all that raising lowmem does not work on newer pc architectures. According to the comments setting the size of lowmem based of the `max-ram-below-4g` option should happen before the gigabyte alignment, not after it. Anyway, it does not make sense because with default being 3 Gb gigabyte alignment always means 3 Gb so raising is not possible at all. The last example of the comment clearly states that raising should be possible using the newest `pc` architecture: `qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)`. However, according to the code below the comment this is not the way it works because gigabyte alignment happens after. + +To solve the problem there are two possibilities: if this is a bug then the solution is obvious, the gigabyte aligment should happen before applying the `max-ram-below-4g` option. If this is not a bug but the expected way of working then there could be an option to override the `gigabyte_align` attribute from command line. + +What do you think? diff --git a/results/classifier/gemma3:12b/device/1716132 b/results/classifier/gemma3:12b/device/1716132 new file mode 100644 index 000000000..f38fb9088 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1716132 @@ -0,0 +1,21 @@ + +Win 10 bitlocker won't initialise pass-through TPM + +All stock Ubuntu Zesty, Win10Pro KVM guest configured with OVMF and Q35. My host has an ASRock Z97 Extreme 6 board with a TPM header which is populated with v1.2 complaint device. + +Testing in my host the TPM device is function, I can tpm_takeownership and tpm_clear successfully and similar testing by passing the device through to a linux guest also succeeds. + +However using Bitlocker in Windows 10 Pro release 1703 Windows advises it cannot "Prepare" the device which I take to mean it cannot take ownership of it. I believe this to be related to Windows inability to view the TCG Event Log which is evidenced in the below 2 screencaps, however I'm no expert. + +https://s26.postimg.org/vter35eh5/Screenshot_20170907_114644.png +https://s26.postimg.org/klo854qyx/Screenshot_20170909_143841.png + +I've also tested the scenario with qemu 2.10 which provided the exact same results. The only difference in the test setup is that I had to make the guest boot with SeaBios instead of OVMF. (Windows wouldn't boot with OVMF with the boot manager giving me an error pointing to a BCD issue. Researching this it seemed related to an old ACPI problem, I believe this unrelated to my TPM issue so will do more research and raise a separate bug for this if needed.) + +Happy to provide further configurations and build logs as necessary so please advise me what is needed. + +Lastly for background reading. I've been trying to get TPM passthrough working with Windows for a long time now and have hit several different issues which I believe have been addressed by both code maturity in Qemu but also in Windows releases. An earlier bug report can be found here (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1615722) which concludes advising me to raise this new/separate issue. + +Thanks in advance, + +Kelvin \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1717 b/results/classifier/gemma3:12b/device/1717 new file mode 100644 index 000000000..bac1e895c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1717 @@ -0,0 +1,30 @@ + +GPU passthrough (NV h100)case vfio Error +Description of problem: +GPU passthrough (NV h100) will case a error + + +qemu-system-x86_64: vfio_err_notifier_handler(0000:17:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest + + +this error happen in centos, redhat linux,ubuntu with some kernel i have try( 5.19.0,6.0,6.2) +The same server insert L4,L40 GPU, will not happen. Only happen on H100 GPU +The same server install esxios. everything is normal. GPU work fine + +With vfio error. there is some idrac log error on my dell server + +``` +A bus fatal error was detected on a component at slot 2. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 23 device 0 function 0. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 22 device 2 function 0. Tue Jun 20 2023 05:51:51 +``` + +Otherwise, I have try to passthrough gpu on dell amd and intel server both. +With AMD CPU , gpu not working in vm. but will not case vfio error +With INTEL CPU, will case vfio error. +Steps to reproduce: +1. Set GPU passthrought +2. Start VM +3. Do something in vm +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1717708 b/results/classifier/gemma3:12b/device/1717708 new file mode 100644 index 000000000..a2affd37f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1717708 @@ -0,0 +1,17 @@ + +QEMU aarch64 can't run Windows ARM64 iso's + +Hi, +recently Windows ARM64 ISOs have been posted on the internet.. +just checked with latest QEMU 2.10 release from +https://qemu.weilnetz.de/w64/qemu-w64-setup-20170830.exe +"h:\qemu\qemu-system-aarch64.exe" -boot d -cdrom h:\iso\16353.1000.170825-1423.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_ES-ES.ISO -m 2048 -cpu cortex-a57 -smp 1 -machine virt +seems no video output.. +checked various machine options for example versatilepb (says guest has not initialized the guest).. + +so don't know if it's a QEMU bug or lacking feature but can support running Windows ARM64 builds (would be nice if you can add a Snapdragon835 machine type which is which first machines will be running..) + + +note running a Windows x64 ISO with similar parameters works (removing -cpu and -machine as not needed) + +thanks.. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1718118 b/results/classifier/gemma3:12b/device/1718118 new file mode 100644 index 000000000..2ef3107b7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1718118 @@ -0,0 +1,26 @@ + +qemu crashes with hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) + +Qemu crashes with error "hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev)" when memory hotplug and hotunplug was done continuously. + +Steps to re-produce: +1. git clone (today's i.e 19th Sept) +2. Bring up ppc64le guest with memory hotplug capabilities ( I used libvirt xml to do this). +3. And do continuous memory hotplug and unplug using the following memory xml (mem_hp_8g.xml) +<memory model='dimm'> +<target> +<size unit='KiB'>8388608</size> +<node>1</node> +</target> +</memory> +4. Run the following +for i in `seq 1 100`; do virsh attach-device nrs mem_hp_8g.xml --live; virsh detach-device nrs mem_hp_8g.xml --live; done +5. Guest will crash +6. Following is from qemu log + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-ppc64 -name guest=nrs,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-nrs/master-key.aes -machine pseries-2.10,accel=kvm,usb=off,dump-guest-core=off -m size=8388608k,slots=256,maxmem=419430400k -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -numa node,nodeid=1,cpus=2-3,mem=4096 -uuid d7987973-2467-43ff-b8d2-acefc6ac59e5 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-19-nrs/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/nasastry/pegas-1.0-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:89:8a:8b,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -s -msg timestamp=on +2017-09-19 06:59:07.878+0000: Domain id=19 is tainted: custom-argv +2017-09-19T06:59:07.918273Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/5 (label charserial0) +** +ERROR:/home/nasastry/qemu/hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) +2017-09-19 06:59:51.428+0000: shutting down, reason=crashed \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1720 b/results/classifier/gemma3:12b/device/1720 new file mode 100644 index 000000000..f1c5d2dbc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1720 @@ -0,0 +1,41 @@ + +Problems in mapping memory regions in multiple machines using GPEX pci-host +Description of problem: +Multiple machines use the GPEX pci-host model. This model forsees 3 MMIO regions: +1. ECAM space +2. MMIO space +3. IO space + +In the different machines, aliases to the 3 memory regions are created which are then mapped onto the sysbus. + +For the ARM virt machine for example following calls are happening: + + ecam_alias = g_new0(MemoryRegion, 1); + ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0); + memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam", ecam_reg, 0, size_ecam); + memory_region_add_subregion(get_system_memory(), base_ecam, ecam_alias); + + mmio_alias = g_new0(MemoryRegion, 1); + mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1); + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +We now add a generic PCIe root port (gen_pcie_root_port.c) on the PCIBus exposed by the GPEX device: + + pci_create_simple(PCI_HOST_BRIDGE(dev)->bus, -1, "pcie-root-port"); + +This device contains an MSI-x table which is accessible via BAR 0. + +However, if we try to access this space we always get 0xFFFFFFFF as a return value on reads because the memory regions are not correctly mapped IMO. + +If we again look at the mapping of the MMIO space: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +The alias is created to the MMIO region in the GPEX device, at offset base_mmio. Afterwards the memory region alias is mapped onto the sysbus at offset base_mmio. To me it seems that the offset is incorrect in creating the alias and should be 0 instead: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, 0, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +With this change the above scenario (accessing the MSI-x table of the generic PCIe root port) is working. I'm not sure if this is the correct fix for this problem and how to cope with e.g. high MMIO regions (as are also present in the virt machine). diff --git a/results/classifier/gemma3:12b/device/1720971 b/results/classifier/gemma3:12b/device/1720971 new file mode 100644 index 000000000..3d89ec32a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1720971 @@ -0,0 +1,14 @@ + +qemu/hw/block/onenand.c:522: strange if statement ? + +[qemu/hw/block/onenand.c:523]: (warning) Opposite inner 'if' condition leads to a dead code block. + +Source code is + + for (b = 0; b < s->blocks; b ++) { + if (b >= s->blocks) { + s->status |= ONEN_ERR_CMD; + break; + } + +Inner if condition will never be true. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1721220 b/results/classifier/gemma3:12b/device/1721220 new file mode 100644 index 000000000..9bedba5b7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1721220 @@ -0,0 +1,16 @@ + +qemu crashes with assertion error `!mr->container' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + +INFO: running test case: machine=bamboo binary=ppc64-softmmu/qemu-system-ppc64 device=pcie-pci-bridge accel=kvm +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine bamboo,accel=kvm -device pcie-pci-bridge +CRITICAL: failed: machine=bamboo binary=ppc64-softmmu/qemu-system-ppc64 device=pcie-pci-bridge accel=kvm +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine bamboo,accel=kvm -device pcie-pci-bridge +CRITICAL: log: qemu-system-ppc64: /home/nasastry/qemu/memory.c:1699: memory_region_finalize: Assertion `!mr->container' failed. +CRITICAL: log: warning: KVM does not support watchdog +CRITICAL: exit code: -6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1721222 b/results/classifier/gemma3:12b/device/1721222 new file mode 100644 index 000000000..ef0b0775e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1721222 @@ -0,0 +1,16 @@ + +qemu crashes with Assertion `fdctrl->dma' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + + +INFO: running test case: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine powernv,accel=tcg -device isa-fdc +CRITICAL: failed: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine powernv,accel=tcg -device isa-fdc +CRITICAL: log: qemu-system-ppc64: hw/block/fdc.c:2703: isabus_fdc_realize: Assertion `fdctrl->dma' failed. +CRITICAL: exit code: -6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1721224 b/results/classifier/gemma3:12b/device/1721224 new file mode 100644 index 000000000..78cb184f9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1721224 @@ -0,0 +1,15 @@ + +qemu crashes with Assertion `!bus->dma[0] && !bus->dma[1]' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + +INFO: running test case: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine prep,accel=tcg -device i82374 +CRITICAL: failed: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine prep,accel=tcg -device i82374 +CRITICAL: log: qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion `!bus->dma[0] && !bus->dma[1]' failed. +CRITICAL: exit code: -6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1722857 b/results/classifier/gemma3:12b/device/1722857 new file mode 100644 index 000000000..4c4b08a5b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1722857 @@ -0,0 +1,6 @@ + +Missing PCI "programming interface" ID emulation for USB host controllers + +Qemu doesn't currently emulate the correct value of the "register level programming interface" field in the PCI config space of USB host controllers. As a result, some guest operating systems (most notably Windows) fail to load e.g. generic xHCI drivers, and instead ask for a vendor-specific driver, which may not be always available. + +Example: "-device nec-usb-xhci" emulates a Renesas (formerly NEC) uPD720202 xHCI controller. However, in the PCI config space, it shows us as class 0C, subclass 03, prog-if 00 (UHCI) where as the real uPD720202 (and all real xHCI controllers) have prog-if 30 (xHCI). A Windows guest booted with this option will not recognize devices attached to the XHCI controller unless drivers from Renesas are manually installed first, even though recent Windows versions include a generic xHCI driver that works perfectly well with real uPD720202 hardware. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1731 b/results/classifier/gemma3:12b/device/1731 new file mode 100644 index 000000000..c0453f3d1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1732177 b/results/classifier/gemma3:12b/device/1732177 new file mode 100644 index 000000000..bfff74eed --- /dev/null +++ b/results/classifier/gemma3:12b/device/1732177 @@ -0,0 +1,6 @@ + +SBSA ACS test freezes inside qemu-system-aarch64 + +In an effort to get Windows 10 for ARM64 (which is supposed to boot on SBSA/SBBR-compliant platforms) to boot inside qemu, I tried to run the SBSA ACS test suite. I used the UEFI image from the latest Linaro snapshot, and built the SBSA ACS UEFI application from https://github.com/ARM-software/sbsa-acs myself using a Linaro aarch64 compiler. + +Test #8 causes an infinite exception loop, as the exception vectors themselves somehow become inaccessible, and accessing them triggers another exception to be handled by the same vector. (With some older Linaro UEFI images, the hard lockup is avoided, and the SBSA UEFI app crashes instead.) If I disable that test, the testsuite locks up in other tests in very similar ways. We aren't even able to get a pass/fail score from the app because of this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1732981 b/results/classifier/gemma3:12b/device/1732981 new file mode 100644 index 000000000..f5e422465 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1732981 @@ -0,0 +1,6 @@ + +usb-net on aarch64 has wrong class IDs, isn't recognized by Windows + +If I run qemu-system-aarch64 with "-device usb-net,...", the resulting USB device will be seen in the guest as class 0x2, subclass 0x2, protocol 0xFF, instead of the expected class 0xe0, subclass 0x1, protocol 0x3. This prevents Windows' in-box class driver from binding to the device. On x86 and x64 Windows, this is not an issue, as another driver will bind to the device, but in Windows for ARM64, that driver is unavailable, so the USB device is incorrectly recognized as a serial port. + +Installing a modified version of the inbox driver in "Disable Driver Signature Enforcement" mode solves the issue, but it's not a very clean solution. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1743214 b/results/classifier/gemma3:12b/device/1743214 new file mode 100644 index 000000000..533a76c83 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1743214 @@ -0,0 +1,7 @@ + +OS/2 Warp 3 support broken in 2.11 + +Hello, I used to run OS/2 Warp 3 on QEMU with the following command line: qemu-system-i386 -vga cirrus -soundhw sb16 -hda os2warp3v2.img -boot c. It runs OK on QEMU 2.10, but immediately gives TRAP 0006 (invalid opcode?) on QEMU 2.11 (see screenshot). +If it is important I have Fixpack 40 and GRADD installed in OS/2. +Here is the image: +https://drive.google.com/open?id=15umPecy7JlPLKUP6520MB_87CfrCDWO5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1744 b/results/classifier/gemma3:12b/device/1744 new file mode 100644 index 000000000..e77374d94 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1744 @@ -0,0 +1,2 @@ + +Divide-by-zero in virtio_gpu_simple_process_cmd diff --git a/results/classifier/gemma3:12b/device/1746 b/results/classifier/gemma3:12b/device/1746 new file mode 100644 index 000000000..f68b5d186 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1746 @@ -0,0 +1,4 @@ + +PIC32 support in QEMU +Additional information: +There is a fork of an older version of QEMU that includes running a PIC32 microcontoller in QEMU hosted [here](https://github.com/sergev/qemu), however, it is very outdated. diff --git a/results/classifier/gemma3:12b/device/1747 b/results/classifier/gemma3:12b/device/1747 new file mode 100644 index 000000000..4547c23f8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1747 @@ -0,0 +1,17 @@ + +eMMC support is missing as a storage type +Additional information: +There seems several attempts at this, but the most recent appears much more complete: +* https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg00347.html + + + +Historical; +"[PATCH v3 06/21] sd: emmc: Update CMD8 to send EXT_CSD register" +https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg00118.html + +"[RFC PATCH 00/17] hw/sd: Rework models for eMMC support" +https://lore.kernel.org/qemu-devel/8aa56da0-a54a-102a-fc85-2fa9f02c18d1@kaod.org/ + +2011 eMMC original support +https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02835.html diff --git a/results/classifier/gemma3:12b/device/1747393 b/results/classifier/gemma3:12b/device/1747393 new file mode 100644 index 000000000..2986c7f23 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1747393 @@ -0,0 +1,4 @@ + +nvme is missing support for NVME_ADM_CMD_ASYNC_EV_REQ + +NVME_ADM_CMD_ASYNC_EV_REQ is required by specification but apparently we will be responded by error when this command is used. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1748756 b/results/classifier/gemma3:12b/device/1748756 new file mode 100644 index 000000000..343cd1d78 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1748756 @@ -0,0 +1,4 @@ + +[Feature request] Support of TI AM1808 for Lego EV3 + +It would be great if emulating TI AM1808 would be possible. It will be a big step towards Lego Mindstorms EV3 emulation. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1756728 b/results/classifier/gemma3:12b/device/1756728 new file mode 100644 index 000000000..c32f374d5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1756728 @@ -0,0 +1,17 @@ + +virtio-scsi virtio-scsi-single and virtio-blk on raw image, games are not starting + +Using virtio-scsi / vitro-scsi-sing and vitro-blk on a ZFS/raw image, most Assassin's Creed (Origin especially) games are not starting (uPlay), it seems related to some check or commands applications are doing on the disk drive that fails to respond. + +Workaround has been found by creating a VHD volume, mounting it and installing games on it. + +On a side note, application like HDDScan, CrystalDiskInfo returns nothing regarding disk drives. + +Guest: +Windows 10 (build 1709) + +Host: +$ kvm --version +QEMU emulator version 2.9.1 pve-qemu-kvm_2.9.1-9 +$ uname -a +Linux xxxx 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1759338 b/results/classifier/gemma3:12b/device/1759338 new file mode 100644 index 000000000..1c5fccc87 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1759338 @@ -0,0 +1,44 @@ + +qemu-system-sparc w/ SS-20 ROM does not add processors + +When booting a SPARCstation-20 with the original ROM, qemu does not set the number of processors in a way that this ROM can understand it, and the ROM always reports only 1 processor installed: + + + ~/qemu /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu "TI SuperSparc 60" -smp 2 -nographic + +Power-ON Reset + + + + + SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95) + + +CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache + +CPU_#1 ******* NOT installed ******* +CPU_#2 ******* NOT installed ******* +CPU_#3 ******* NOT installed ******* + + <<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = 00000008) + + +... + +Cpu #0 TI,TMS390Z50 +Cpu #1 Nothing there +Cpu #2 Nothing there +Cpu #3 Nothing there + +... + +SPARCstation 20 (1 X 390Z50), No Keyboard +ROM Rev. 2.25, 128 MB memory installed, Serial #1193046. +Ethernet address 52:54:0:12:34:56, Host ID: 72123456. + + + + +(It is necessary use SS-20 since it is the only sun4m model that supports 512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) + +When booting with OpenBIOS I can't seem to boot any version of Solaris though I had heard this did work. Solaris 8 and 9 do work nicely with this ROM, but I am opening this to see if it is possible to fix this to allow the original OBP ROM to see multiple processors. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1761 b/results/classifier/gemma3:12b/device/1761 new file mode 100644 index 000000000..b83a9a617 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1761 @@ -0,0 +1,2 @@ + +vexpress-a9 board maps both RAM and flash at address 0 diff --git a/results/classifier/gemma3:12b/device/1762 b/results/classifier/gemma3:12b/device/1762 new file mode 100644 index 000000000..fa32851ec --- /dev/null +++ b/results/classifier/gemma3:12b/device/1762 @@ -0,0 +1,84 @@ + +Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF +Description of problem: +Running: + +``` +hwclock --hctosys +``` + +as root, under the running VM using a UEFI bios image, I get: + +``` +hwclock: select() to /dev/rtc0 to wait for clock tick timed out +``` + +When running the same command on the same disk image but without UEFI, +that is, just using the SeaBIOS bios, everything works fine. + +Running + +``` +hwclock --hctosys --directisa +``` + +works fine, too. + +Running the (compiled) kernel test utility: + + +``` +/usr/src/linux/tools/testing/selftests/rtc/rtctest.c + +``` + + +``` +TAP version 13 +1..8 +# Starting 8 tests from 2 test cases. +# RUN rtc.date_read ... +# rtctest.c:49:date_read:Current RTC date/time is 10/07/2023 14:02:11. +# OK rtc.date_read +ok 1 rtc.date_read +# RUN rtc.date_read_loop ... +# rtctest.c:88:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read). +# rtctest.c:115:date_read_loop:Performed 2752 RTC time reads. +# OK rtc.date_read_loop +ok 2 rtc.date_read_loop +# RUN rtc.uie_read ... +# uie_read: Test terminated by timeout +# FAIL rtc.uie_read +not ok 3 rtc.uie_read +# RUN rtc.uie_select ... +# rtctest.c:164:uie_select:Expected 0 (0) != rc (0) +# uie_select: Test terminated by assertion +# FAIL rtc.uie_select +not ok 4 rtc.uie_select +# RUN rtc.alarm_alm_set ... +# rtctest.c:202:alarm_alm_set:Alarm time now set to 14:02:52. +# rtctest.c:214:alarm_alm_set:Expected 0 (0) != rc (0) +# alarm_alm_set: Test terminated by assertion +# FAIL rtc.alarm_alm_set +not ok 5 rtc.alarm_alm_set +# RUN rtc.alarm_wkalm_set ... +# rtctest.c:258:alarm_wkalm_set:Alarm time now set to 10/07/2023 14:02:57. +# rtctest.c:268:alarm_wkalm_set:Expected 0 (0) != rc (0) +# alarm_wkalm_set: Test terminated by assertion +# FAIL rtc.alarm_wkalm_set +not ok 6 rtc.alarm_wkalm_set +# RUN rtc.alarm_alm_set_minute ... +# rtctest.c:304:alarm_alm_set_minute:Alarm time now set to 14:03:00. +# rtctest.c:316:alarm_alm_set_minute:Expected 0 (0) != rc (0) +# alarm_alm_set_minute: Test terminated by assertion +# FAIL rtc.alarm_alm_set_minute +not ok 7 rtc.alarm_alm_set_minute +# RUN rtc.alarm_wkalm_set_minute ... +# rtctest.c:360:alarm_wkalm_set_minute:Alarm time now set to 10/07/2023 14:05:00. +# rtctest.c:370:alarm_wkalm_set_minute:Expected 0 (0) != rc (0) +# alarm_wkalm_set_minute: Test terminated by assertion +# FAIL rtc.alarm_wkalm_set_minute +not ok 8 rtc.alarm_wkalm_set_minute +# FAILED: 2 / 8 tests passed. +# Totals: pass:2 fail:6 xfail:0 xpass:0 skip:0 error:0 +# diff --git a/results/classifier/gemma3:12b/device/1764 b/results/classifier/gemma3:12b/device/1764 new file mode 100644 index 000000000..d3d7a0dfb --- /dev/null +++ b/results/classifier/gemma3:12b/device/1764 @@ -0,0 +1,2 @@ + +lsusb fails with qemu-system-x86_64 command (qemu-system-x86 package) diff --git a/results/classifier/gemma3:12b/device/1766904 b/results/classifier/gemma3:12b/device/1766904 new file mode 100644 index 000000000..7def98bec --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1767 b/results/classifier/gemma3:12b/device/1767 new file mode 100644 index 000000000..cb1bc0fb3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1767 @@ -0,0 +1,4 @@ + +Add iphone emulated device +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1767126 b/results/classifier/gemma3:12b/device/1767126 new file mode 100644 index 000000000..9fddb6dba --- /dev/null +++ b/results/classifier/gemma3:12b/device/1767126 @@ -0,0 +1,13 @@ + +Man page documents qemu -drive if=scsi but it no longer works + +The qemu man page section documenting the -drive option contains + + if=interface + This option defines on which type on interface the drive is + connected. Available types are: ide, scsi, sd, mtd, floppy, + pflash, virtio, none. + +but if=scsi no longer works as of version 2.12.0. + +If you really have to make backwards incompatible changes, it would be helpful if you could at least document them. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1767176 b/results/classifier/gemma3:12b/device/1767176 new file mode 100644 index 000000000..314ca5554 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1767176 @@ -0,0 +1,47 @@ + +GTK build fails with qemu 2.12.0 + +With the 2.12.0 release of QEMU passing `--enable-gtk` to configure causes the build to fail. I'm running macOS 10.13.5 with Xcode 9.3 FWIW. + +I'm building against GTK 2.24.32, which I appreciate is no longer the preferred version here, but I don't think the error is related to that aspect. I'll try and find the time later to attempt a GTK3 build to check that though. + +``` +ui/gtk.c:1147:16: error: use of undeclared identifier 'qemu_input_map_osx_to_qcode'; did you mean 'qemu_input_map_usb_to_qcode'? + return qemu_input_map_osx_to_qcode; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + qemu_input_map_usb_to_qcode +/private/tmp/qemu-20180426-60786-1av6pq8/qemu-2.12.0/include/ui/input.h:99:22: note: 'qemu_input_map_usb_to_qcode' declared here +extern const guint16 qemu_input_map_usb_to_qcode[]; + ^ +``` + +I tried poking around locally by applying the following diff, based off of a very brief glance over the code involved, but that simply causes the build to error out in a different way at a later point, so I assume I'm doing something stupid. + + +``` +diff --git a/Makefile b/Makefile +index d71dd5b..e857c3c 100644 +--- a/Makefile ++++ b/Makefile +@@ -313,6 +313,7 @@ KEYCODEMAP_FILES = \ + ui/input-keymap-qnum-to-qcode.c \ + ui/input-keymap-usb-to-qcode.c \ + ui/input-keymap-win32-to-qcode.c \ ++ ui/input-keymap-osx-to-qcode.c \ + ui/input-keymap-x11-to-qcode.c \ + ui/input-keymap-xorgevdev-to-qcode.c \ + ui/input-keymap-xorgkbd-to-qcode.c \ +diff --git a/include/ui/input.h b/include/ui/input.h +index 16395ab..8183840 100644 +--- a/include/ui/input.h ++++ b/include/ui/input.h +@@ -101,6 +101,9 @@ extern const guint16 qemu_input_map_usb_to_qcode[]; + extern const guint qemu_input_map_win32_to_qcode_len; + extern const guint16 qemu_input_map_win32_to_qcode[]; + ++extern const guint qemu_input_map_osx_to_qcode_len; ++extern const guint16 qemu_input_map_osx_to_qcode[]; ++ + extern const guint qemu_input_map_x11_to_qcode_len; + extern const guint16 qemu_input_map_x11_to_qcode[]; +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1771042 b/results/classifier/gemma3:12b/device/1771042 new file mode 100644 index 000000000..f659fd8eb --- /dev/null +++ b/results/classifier/gemma3:12b/device/1771042 @@ -0,0 +1,15 @@ + +dataplane interrupt handler doesn't support msi + +hw/block/dataplane/virtio-blk.c commit 1010cadf62332017648abee0d7a3dc7f2eef9632 + +in the function notify_guest_bh, the function virtio_notify_irqfd is called +to deliver the interrupt corresponding to the vq + +however, without the dataplane, hw/block/virtio_blk_req_complete calls +virtio_notify to deliver the interrupt (immediately). this goes though +a slightly more involved path that calls virtio_pci_notify which includes +a case to handle msi interrupts. + +so, msi interrupts with block devices aren't serviced when using dataplane +batching. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1771238 b/results/classifier/gemma3:12b/device/1771238 new file mode 100644 index 000000000..3f582294d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1772 b/results/classifier/gemma3:12b/device/1772 new file mode 100644 index 000000000..e101ad05e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1772 @@ -0,0 +1,13 @@ + +MPS2 AN521 has the wrong number of MPU region defined +Description of problem: +The AN521 is integrating SSE-200 on the MPS2+ FPGA prototyping board. +The current implementation in qemu behaves as though there are 16MPU regions when it really only has 8, as describes as `MPU_NS` and `MPU_S` core configuration parameters in the SSE-200's [Techincal Reference Manual](https://developer.arm.com/documentation/101104/0200/functional-description/cpu-elements/cortex-m33-configurations?lang=en). +Steps to reproduce: +1. Prepare your Zephyr dev environment +2. fix `boards/arm/mps2_an521/mps2_an521.dts` to set `arm,num-mpu-regions` to the appropriate value of 8. +3. build a Zephyr test such as `west build -p -b mps2_an521 -T tests/kernel/interrupt/arch.interrupt` +4. run `qemu-system-arm -machine mps2-an521 -chardev stdio,id=con,mux=on -serial chardev:con -kernel ./build/zephyr/zephyr.elf` +Additional information: +With matching MPU region number in QEMU and Zephyr's DTS, the application shows the test suite's progress & outcome. +If there's a mismatch, the application will enter a fault and not display the expected traces. diff --git a/results/classifier/gemma3:12b/device/1776760 b/results/classifier/gemma3:12b/device/1776760 new file mode 100644 index 000000000..d808e4b2d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1777232 b/results/classifier/gemma3:12b/device/1777232 new file mode 100644 index 000000000..186fbd8f3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1777235 b/results/classifier/gemma3:12b/device/1777235 new file mode 100644 index 000000000..8d23de14a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1777235 @@ -0,0 +1,4 @@ + +NVME is missing support for Get Log Page command + +"Get Log Page" is a mandatory admin command by the specification (NVMe 1.2, Section 5, Figure 40) currently not implemented by device. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1777236 b/results/classifier/gemma3:12b/device/1777236 new file mode 100644 index 000000000..8f99b5781 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1777236 @@ -0,0 +1,12 @@ + +NVME is missing support for mandatory features through "Get/Set Feature" command + +The following are features which are marked as mandatory by the 1.2 specification (NVMe 1.2, Section 5.14.1, Figure 108) as currently not implemented + - 0x1 Arbitration + - 0x2 Power Management + - 0x4 Temperature Threshold + - 0x5 Error Recovery + - 0x6 Interrupt Coalescing + - 0x7 Interrupt Vector Configuration + - 0x8 Write Atomicity Normal + - 0x9 Asynchronous Event Configuration \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1777315 b/results/classifier/gemma3:12b/device/1777315 new file mode 100644 index 000000000..a0c325f89 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1777315 @@ -0,0 +1,73 @@ + +IDE short PRDT abort + +Hi, +QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0 + +run the program in qemu-2.12.0: +#define _GNU_SOURCE +#include <endian.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <fcntl.h> +#include <stdio.h> +#include <string.h> +#include <sys/stat.h> +#include <stdint.h> +#include <string.h> + +static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2) +{ + if (a0 == 0xc || a0 == 0xb) { + char buf[128]; + sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2); + return open(buf, O_RDWR, 0); + } else { + char buf[1024]; + char* hash; +strncpy(buf, (char*)a0, sizeof(buf) - 1); + buf[sizeof(buf) - 1] = 0; + while ((hash = strchr(buf, '#'))) { + *hash = '0' + (char)(a1 % 10); + a1 /= 10; + } + return open(buf, a2, 0); + } +} + +uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; +void loop() +{ + long res = 0; +memcpy((void*)0x20000000, "/dev/sg#", 9); + res = syz_open_dev(0x20000000, 0, 2); + if (res != -1) + r[0] = res; + res = syscall(__NR_dup2, r[0], r[0]); + if (res != -1) + r[1] = res; +*(uint8_t*)0x20000ec0 = 0; +*(uint8_t*)0x20000ec1 = 0; +*(uint8_t*)0x20000ec2 = 0; +*(uint8_t*)0x20000ec3 = 0; +*(uint32_t*)0x20000ec8 = 0; +*(uint8_t*)0x20000ed8 = 0; +*(uint8_t*)0x20000ed9 = 0; +*(uint8_t*)0x20000eda = 0; +*(uint8_t*)0x20000edb = 0; +memcpy((void*)0x20000ee0, "\x9c\x4d\xe7\xd5\x0a\x62\x43\xa7\x77\x53\x67\xb3", 12); + syscall(__NR_write, r[1], 0x20000ec0, 0x323); +} + +int main() +{ + syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); + loop(); + return 0; +} +this will crash qemu, output information: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + + +Thanks +owl337 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1777969 b/results/classifier/gemma3:12b/device/1777969 new file mode 100644 index 000000000..7198db817 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1777969 @@ -0,0 +1,67 @@ + +Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0 + +I am getting a crash when booting <= SystemRescueCD 4.3.0 in UEFI mode with q35 machine and from a AHCI device with qemu 2.11.1 and 2.12.0. The crash doesn't occur if I compile with --enable-trace-backends=simple or if I use virtio-scsi. The original crash was noticed on Gentoo with hardened gcc 6.4.0 and an Intel CPU, the test system to reproduce the crash is on Gentoo with non-hardened gcc 5.4.0 and an Intel CPU. + +OVMF version is from Gentoo: edk2-ovmf-2017_p20180211-bin.tar.xz + +Here is the commands I have run on qemu 2.12.0 to reproduce the issue although it also crashes with accel=kvm removed: +./configure --target-list="x86_64-softmmu" +make +qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -cpu qemu64 -drive if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -m 512 -drive file=systemrescuecd-x86-4.3.0.iso,if=none,id=cdrom-sysresc,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=cdrom-sysresc,bootindex=5 -device VGA -display gtk + +Valgrind says "Bad permissions for mapped region at address 0x4C022FE0" for the crash. + +Here is a backtrace from gdb: +Program received signal SIGSEGV, Segmentation fault. +0x00007f42dcbc5833 in malloc () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007f42dcbc5833 in malloc () from /lib64/libc.so.6 +#1 0x00007f42e10117d9 in g_malloc () from /usr/lib64/libglib-2.0.so.0 +#2 0x000055a3ff9def8f in qemu_aio_get (aiocb_info=aiocb_info@entry=0x55a4001b39a0 <thread_pool_aiocb_info>, bs=bs@entry=0x0, cb=cb@entry=0x55a3ff9dfe20 <thread_pool_co_cb>, opaque=opaque@entry=0x7f42961e30b0) at util/aiocb.c:33 +#3 0x000055a3ff9e0249 in thread_pool_submit_aio (pool=pool@entry=0x55a400c038d0, func=func@entry=0x55a3ff956620 <aio_worker>, arg=arg@entry=0x55a400bd30b0, cb=cb@entry=0x55a3ff9dfe20 <thread_pool_co_cb>, + opaque=opaque@entry=0x7f42961e30b0) at util/thread-pool.c:251 +#4 0x000055a3ff9e0423 in thread_pool_submit_co (pool=0x55a400c038d0, func=func@entry=0x55a3ff956620 <aio_worker>, arg=arg@entry=0x55a400bd30b0) at util/thread-pool.c:289 +#5 0x000055a3ff956b50 in paio_submit_co (bs=0x55a400bff180, fd=<optimized out>, offset=362702848, qiov=<optimized out>, bytes=2048, type=1) at block/file-posix.c:1536 +#6 0x000055a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bff180, offset=offset@entry=362702848, bytes=bytes@entry=2048, qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924 +#7 0x000055a3ff960154 in bdrv_aligned_preadv (child=child@entry=0x55a400c03a20, req=req@entry=0x7f42961e32e0, offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=1, qiov=qiov@entry=0x7f42961e3650, flags=0) + at block/io.c:1228 +#8 0x000055a3ff960434 in bdrv_co_preadv (child=0x55a400c03a20, offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/io.c:1324 +#9 0x000055a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bf8e50, offset=offset@entry=362702848, bytes=bytes@entry=2048, qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924 +#10 0x000055a3ff960154 in bdrv_aligned_preadv (child=child@entry=0x55a400be92c0, req=req@entry=0x7f42961e3510, offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=512, qiov=qiov@entry=0x7f42961e3650, flags=0) + at block/io.c:1228 +#11 0x000055a3ff960434 in bdrv_co_preadv (child=0x55a400be92c0, offset=offset@entry=362702848, bytes=bytes@entry=2048, qiov=qiov@entry=0x7f42961e3650, flags=flags@entry=0) at block/io.c:1324 +#12 0x000055a3ff94f4ce in blk_co_preadv (blk=0x55a400bf8ba0, offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/block-backend.c:1158 +#13 0x000055a3ff94f5ac in blk_read_entry (opaque=0x7f42961e3670) at block/block-backend.c:1206 +#14 0x000055a3ff94e000 in blk_prw (blk=0x55a400bf8ba0, offset=362702848, buf=<optimized out>, bytes=bytes@entry=2048, co_entry=co_entry@entry=0x55a3ff94f590 <blk_read_entry>, flags=flags@entry=0) at block/block-backend.c:1243 +#15 0x000055a3ff94f076 in blk_pread (blk=<optimized out>, offset=<optimized out>, buf=<optimized out>, count=count@entry=2048) at block/block-backend.c:1409 +#16 0x000055a3ff7d8b93 in cd_read_sector_sync (s=0x55a401a0faa0) at hw/ide/atapi.c:124 +#17 ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:269 +#18 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#19 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#20 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#21 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#22 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#23 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#24 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#25 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#26 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#27 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#28 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#29 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#30 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#31 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#32 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#33 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#34 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#35 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#36 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#37 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#38 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#39 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#40 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#41 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#42 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#43 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#44 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#45 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1779120 b/results/classifier/gemma3:12b/device/1779120 new file mode 100644 index 000000000..c4c34abb0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1779120 @@ -0,0 +1,19 @@ + +disk missing in the guest contingently when hotplug several virtio scsi disks consecutively + +Hi, I found a bug that disk missing (not all disks missing ) in the guest contingently when hotplug several virtio scsi disks consecutively. After rebooting the guest,the missing disks appear again. + +The guest is centos7.3 running on a centos7.3 host and the scsi controllers are configed with iothread. The scsi controller xml is below: + + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='26'/> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + + +If the scsi controllers are configed without iothread, disks are all can be seen in the guest when hotplug several virtio scsi disks consecutively. + +I think the biggest difference between them is that scsi controllers with iothread call virtio_notify_irqfd to notify guest and scsi controllers without + +iothread call virtio_notify instead. What make it difference? Will interrupts are lost when call virtio_notify_irqfd due to race condition for some unknow reasons? Maybe guys more familiar with scsi dataplane can help. Thanks for your reply! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1787070 b/results/classifier/gemma3:12b/device/1787070 new file mode 100644 index 000000000..d5a4a06cc --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1788 b/results/classifier/gemma3:12b/device/1788 new file mode 100644 index 000000000..31c85b48a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1788 @@ -0,0 +1,30 @@ + +Floating point rounding fails on mps3-an547 amd cortex-m55 while using LLVM-embedded-toolchain-for-Arm and Picolibic. +Description of problem: +Rounding of long double gives unexpected result. Simple code as example: +``` +#include <math.h> +int main(void) +{ + long double value = -8.5L; + long rounded_value = lrintl(value); + if( -8 == rounded_value ) + { + return 0; + } + return 1; +} +``` +Steps to reproduce: +1. Checkout project: [LLVM-embedded-toolchain-for-ARM](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm) +2. Configure it with option -DLLVM_TOOLCHAIN_LIBRARY_VARIANTS=armv8.1m.main_hard_nofp_mve +3. Build project +4. Run Picolbic tests with ninja picolibc_armv8.1m.main_hard_nofp_mve-test + +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. +Additional information: +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. diff --git a/results/classifier/gemma3:12b/device/179 b/results/classifier/gemma3:12b/device/179 new file mode 100644 index 000000000..27a36a640 --- /dev/null +++ b/results/classifier/gemma3:12b/device/179 @@ -0,0 +1,2 @@ + +qemu guest crashes on spice client USB redirected device removal diff --git a/results/classifier/gemma3:12b/device/1793859 b/results/classifier/gemma3:12b/device/1793859 new file mode 100644 index 000000000..d617c1eb9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1794 b/results/classifier/gemma3:12b/device/1794 new file mode 100644 index 000000000..4e5d2e0fe --- /dev/null +++ b/results/classifier/gemma3:12b/device/1794 @@ -0,0 +1,28 @@ + +Virtio-GPU doesn't fill Response data for cursor queue +Description of problem: +Implementation of virtio-gpu in Qemu is likely not fill Response header in cursor commands. + +Inside the virtio 1.2 specification, document said: +``` +VIRTIO_GPU_CMD_UPDATE_CURSOR + Update cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA. + Full cursor update. Cursor will be loaded from the specified resource_id and will be moved to pos. The driver must + transfer the cursor into the resource beforehand (using control queue commands) and make sure the commands to fill + the resource are actually processed (using fencing). + +VIRTIO_GPU_CMD_MOVE_CURSOR + Move cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA. + Move cursor to the place specified in pos. The other fields are not used and will be ignored by the device. +``` +The cursor commands do have a response like control commands. + +But in [hw/display/virtio-gpu.c#L1136](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu.c#L1136), QEMU doesn't care anything about response, just fetching command and execute. + +It this a Implementation compromise or I missing something in the specification? +Steps to reproduce: +1. Write any kernel that using virtio-gpu. +2. Run on qemu. +3. No response on cursor command. +Additional information: +Specification: [virtio-v1.2-cs01.html](https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007) diff --git a/results/classifier/gemma3:12b/device/1794187 b/results/classifier/gemma3:12b/device/1794187 new file mode 100644 index 000000000..4c0097fe7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1794187 @@ -0,0 +1,15 @@ + +improve error message, when using raspi3 and RAM>4G + +Running `qemu-system-aarch64 image-aarch64.iso --machine raspi3 -m 8G` prints this error message: + +``` +Unexpected error in visit_type_uintN() at /builddir/build/BUILD/qemu-3.0.0/qapi/qapi-visit-core.c:164: +qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t +``` + +The problem is, that you musn't use more than 4 GB RAM for machine raspi3. As it took me some time to figure that out, I'd be glad, if you can print better error message, like you do, when using more than 4 CPU cores with machine raspi3: + +``` +Invalid SMP CPUs 8. The max CPUs supported by machine 'raspi3' is 4 +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1794939 b/results/classifier/gemma3:12b/device/1794939 new file mode 100644 index 000000000..a8b15db6c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1794939 @@ -0,0 +1,18 @@ + +QEMU does not build with vte v2.91 + +when I build qemu with vte support and vte-2.91 installed I get the following deprecation warning: + +error: ‘vte_terminal_set_encoding’ is deprecated [-Werror=deprecated-declarations] + vte_terminal_set_encoding(VTE_TERMINAL(vc->vte.terminal), "UTF-8", NULL); + ^~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from /usr/include/vte-2.91/vte/vte.h:35 + +I looked for the commit in vte that deprecated the offending function (a17e714d), which led me to the thread: + +https://gitlab.gnome.org/GNOME/vte/issues/3 + +It looks like from this version forward vte forces us to use utf-8, such that this function call becomes unnecessary in QEMU. + +Cheers, +Bastian \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1798434 b/results/classifier/gemma3:12b/device/1798434 new file mode 100644 index 000000000..385c454fc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1798434 @@ -0,0 +1,6 @@ + +[Feature Request] Automatic device configuration discovery + +Would it be possible to have a script that enumerates the device tree of a Linux host and generates a qemu command line that would recreate it under emulation? The user would have to customize the arguments (for instance to point to disk image files), but it would take a lot of the guesswork out. + +Similarly, is there information that can be gleaned from the kernel build config that would help with configuration? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1798780 b/results/classifier/gemma3:12b/device/1798780 new file mode 100644 index 000000000..91a9c1e37 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1798780 @@ -0,0 +1,14 @@ + +hw/usb/dev-mtp.c:1616: bad test ? + +hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical-op] + +Source code is + + if ((ret == -1) && (errno != EINTR || errno != EAGAIN || + errno != EWOULDBLOCK)) { + +Maybe better code + + if ((ret == -1) && (errno != EINTR && errno != EAGAIN && + errno != EWOULDBLOCK)) { \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1799766 b/results/classifier/gemma3:12b/device/1799766 new file mode 100644 index 000000000..086a2b5c7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1799768 b/results/classifier/gemma3:12b/device/1799768 new file mode 100644 index 000000000..94f9136a9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1799768 @@ -0,0 +1,6 @@ + +-nodefaults has unclear documentation + +-nodefaults has an unclear documentation, I believe it should states it does not applies to devices created by a machine model. + +See https://stackoverflow.com/questions/52908614/qemu-s-nodefaults-not-working-as-expected-to-me to read how I came to this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1799919 b/results/classifier/gemma3:12b/device/1799919 new file mode 100644 index 000000000..9e4ece285 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1799919 @@ -0,0 +1,14 @@ + +IDE HDD emulation random read/write errors + +I unfortunately can’t give more tracks other than how to reproduce the bug, especially that the bug occurs randomly. + +Basically, I’m trying to install DOS 6.22 on an emulated ISA machine, and it fails, DOS complaining about read or write error on drive C. Repeating the operation multiple time, I see it occurs at random stage, sometime even before it partitions the drive, sometime when it formats the drive, sometime when it copies the files from the floppy to the drive. + +To test it, unpack the attached archive and execute `./run` from the extracted directory. The archive contains three raw floppy images for installing DOS 6.22, and a Bourne Shell script which invokes QEmu. Just press enter at any installation stage, the bug may occurs at any stage. + +I tried with `cache=none` to be sure it’s not a cache issue, but its the same whatever the cache policy is. + +Version and environment: using QEmu 3.0 on Ubuntu 16.04 on a 32 bits DELL Inspiron 9400 (not an emulation, that’s my real laptop). + +For why I’m using QEmu for this: the installation proceeds with not error in VirtualBox, but I wanted to use QEmu to have a serial mouse which is not available with QEmu and to have finer control over the machine configuration ; VirtualBox although good, is more limited in that regard. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1800088 b/results/classifier/gemma3:12b/device/1800088 new file mode 100644 index 000000000..3535498c3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1800088 @@ -0,0 +1,8 @@ + +Assertion fail while usb camera redirect + +This may happen during usb camera redirect. But if i move the camera lens from left to right or up to down, this always happen. My qemu-version is 2.10.0 and following is the error information: + +2018-10-26T03:37:54.925231Z qemu-kvm: usbredirparser: error unexpected extra data ep 00 +qemu-kvm: hw/usb/redirect.c:1313: usbredir_chardev_read: Assertion `dev->read_buf == ((void *)0)' failed. +2018-10-26 03:37:57.120+0000: shutting down, reason=crashed \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1800786 b/results/classifier/gemma3:12b/device/1800786 new file mode 100644 index 000000000..3adc5055c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1800786 @@ -0,0 +1,55 @@ + +USB assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed + +Qemu crashed after starting and stopping VM for many times, and the final log shows below. + +qemu-system-x86_64: hw/usb/dev-storage.c:236: usb_msd_send_status: Assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed. +2018-10-05 15:33:11.261+0000: shutting down + +I got the back trace in coredump file: + +-----------------------back trace---------------------------------------- +#0 0x00007fc890e6cff9 in __GI_raise (sig=sig@entry=6) + at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007fc890e700f8 in __GI_abort () at abort.c:89 +#2 0x00007fc890e66216 in __assert_fail_base ( + fmt=0x7fc890f9dfc0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x7fc8957cd460 "s->csw.sig == cpu_to_le32(0x53425355)", file=file@entry=0x7fc8957cd2d0 "hw/usb/dev-storage.c", + line=line@entry=236, + function=function@entry=0x7fc8957cd5e0 <__PRETTY_FUNCTION__.29765> "usb_msd_send_status") at assert.c:92 +#3 0x00007fc890e662c2 in __GI___assert_fail ( + assertion=assertion@entry=0x7fc8957cd460 "s->csw.sig == cpu_to_le32(0x53425355)", file=file@entry=0x7fc8957cd2d0 "hw/usb/dev-storage.c", + line=line@entry=236, + function=function@entry=0x7fc8957cd5e0 <__PRETTY_FUNCTION__.29765> "usb_msd_send_status") at assert.c:101 +#4 0x00007fc8955dee12 in usb_msd_send_status (s=0x7fc8961588f0, + p=<optimized out>) at hw/usb/dev-storage.c:236 +#5 0x00007fc8955df092 in usb_msd_handle_data (dev=0x7fc8961588f0, + p=0x7fc896105260) at hw/usb/dev-storage.c:507 +#6 0x00007fc8955d5940 in usb_handle_packet (dev=<optimized out>, + p=p@entry=0x7fc896105260) at hw/usb/core.c:407 +#7 0x00007fc8955ea8a8 in uhci_handle_td (s=s@entry=0x7fc896133080, +---Type <return> to continue, or q <return> to quit--- + q=0x7fc896197c90, q@entry=0x0, qh_addr=qh_addr@entry=253943810, + td=td@entry=0x7ffcc646c0e0, td_addr=<optimized out>, + int_mask=int_mask@entry=0x7ffcc646c0cc) at hw/usb/hcd-uhci.c:911 +#8 0x00007fc8955eada9 in uhci_process_frame (s=s@entry=0x7fc896133080) + at hw/usb/hcd-uhci.c:1091 +#9 0x00007fc8955eaff5 in uhci_frame_timer (opaque=0x7fc896133080) + at hw/usb/hcd-uhci.c:1190 +#10 0x00007fc895636c69 in timerlist_run_timers (timer_list=0x7fc896093af0) + at qemu-timer.c:491 +#11 0x00007fc895636f01 in qemu_clock_run_timers (type=<optimized out>) + at qemu-timer.c:502 +#12 qemu_clock_run_all_timers () at qemu-timer.c:608 +#13 0x00007fc8955f9b0c in main_loop_wait (nonblocking=<optimized out>) + at main-loop.c:507 +#14 0x00007fc8954bc750 in main_loop () at vl.c:2021 +#15 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at vl.c:4447 +------------------------------------------------------------------------------- + +QEMU release version: 1.7.2 + +QEMU command: + +qemu-system-x86_64 -enable-kvm -name guest=guest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-42-guest/master-key.aes -machine pc-i440fx-xenial,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge-IBRS,ss=on,vmx=on,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,ssbd=on,xsaveopt=on -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid f4fdccb5-8c59-441f-9a78-83d23fbc34f6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-42-guest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -kernel /nfsroot/rootfs/root/bzImage -initrd /nfsroot/rootfs/root/wrlinux-image-initramfs-x86-64-kvm-guest.cpio.gz -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x7 -device ahci,id=sata0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/nfsroot/rootfs.ovp6/wrlinux-image-ovp-kvm-intel-x86-64-20181015084008.rootfs.ext3,format=raw,if=none,id=drive-usb-disk0 -device usb-storage,bus=usb.0,port=1,drive=drive-usb-disk0,id=usb-disk0,bootindex=1,removable=off -netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:93:6b:0c,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 -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 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1804323 b/results/classifier/gemma3:12b/device/1804323 new file mode 100644 index 000000000..0419e6659 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1804323 @@ -0,0 +1,122 @@ + +qemu segfaults in virtio-scsi driver if underlying device returns -EIO + +Reported downstream in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1650975 + +Using qemu from git and reasonably recent nbdkit, this command injects -EIO +errors into the block device which virtio-scsi is reading from: + +$ nbdkit --filter=error memory size=64M error-rate=100% \ + --run 'x86_64-softmmu/qemu-system-x86_64 -device virtio-scsi,id=scsi -drive file=$nbd,format=raw,id=hd0,if=none -device scsi-hd,drive=hd0' +nbdkit: memory[1]: error: injecting EIO error into pread +nbdkit: memory[1]: error: injecting EIO error into pread +qemu-system-x86_64: hw/scsi/scsi-bus.c:1374: scsi_req_complete: Assertion `req->status == -1' failed. + +The stack trace is: + +Thread 5 (Thread 0x7f33e1f8b700 (LWP 10474)): +#0 0x00007f33fe0bf371 in __GI___poll (fds=0x559b07199490, nfds=1, timeout=-1) + at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007f34061df5e6 in () at /lib64/libglib-2.0.so.0 +#2 0x00007f34061df710 in g_main_context_iteration () + at /lib64/libglib-2.0.so.0 +#3 0x00007f34061df761 in () at /lib64/libglib-2.0.so.0 +#4 0x00007f34062086ea in () at /lib64/libglib-2.0.so.0 +#5 0x00007f33fe19b58e in start_thread (arg=<optimized out>) + at pthread_create.c:486 +#6 0x00007f33fe0ca593 in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 4 (Thread 0x7f33e3fff700 (LWP 10473)): +#0 0x00007f33fe1a4a8d in __lll_lock_wait () + at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 +#1 0x00007f33fe19ddf8 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x559b054697a0 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:78 +#2 0x0000559b04f6b103 in qemu_mutex_lock_impl (mutex=0x559b054697a0 <qemu_global_mutex>, file=0x559b04f87041 "/home/rjones/d/qemu/exec.c", line=3197) + at util/qemu-thread-posix.c:66 +#3 0x0000559b04b722ee in qemu_mutex_lock_iothread_impl (file=file@entry=0x559b04f87041 "/home/rjones/d/qemu/exec.c", line=line@entry=3197) + at /home/rjones/d/qemu/cpus.c:1845 +#4 0x0000559b04b31859 in prepare_mmio_access (mr=<optimized out>, mr=<optimized out>) at /home/rjones/d/qemu/exec.c:3197 +#5 0x0000559b04b381d4 in address_space_ldub (as=<optimized out>, addr=<optimized out>, attrs=..., result=result@entry=0x0) + at /home/rjones/d/qemu/memory_ldst.inc.c:188 +#6 0x0000559b04c61cd0 in helper_inb (env=<optimized out>, port=<optimized out>) at /home/rjones/d/qemu/target/i386/cpu.h:1846 +#7 0x00007f33e889dc3e in code_gen_buffer () +#8 0x0000559b04bb3b87 in cpu_tb_exec (itb=<optimized out>, cpu=0x7f33e8876100 <code_gen_buffer+684243>) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:171 +#9 0x0000559b04bb3b87 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7f33e8876100 <code_gen_buffer+684243>) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:615 +#10 0x0000559b04bb3b87 in cpu_exec (cpu=cpu@entry=0x559b05db57a0) + at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:725 +#11 0x0000559b04b7088f in tcg_cpu_exec (cpu=0x559b05db57a0) + at /home/rjones/d/qemu/cpus.c:1425 +#12 0x0000559b04b72c03 in qemu_tcg_cpu_thread_fn (arg=0x559b05db57a0) + at /home/rjones/d/qemu/cpus.c:1729 +#13 0x0000559b04b72c03 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x559b05db57a0) + at /home/rjones/d/qemu/cpus.c:1703 +#14 0x0000559b04f6afba in qemu_thread_start (args=<optimized out>) + at util/qemu-thread-posix.c:498 +#15 0x00007f33fe19b58e in start_thread (arg=<optimized out>) + at pthread_create.c:486 +#16 0x00007f33fe0ca593 in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 3 (Thread 0x7f33e178a700 (LWP 10475)): +#0 0x00007f33fe0bf371 in __GI___poll (fds=0x559b071aa760, nfds=2, timeout=-1) + at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007f34061df5e6 in () at /lib64/libglib-2.0.so.0 +#2 0x00007f34061df9a2 in g_main_loop_run () at /lib64/libglib-2.0.so.0 +#3 0x00007f34032ca90a in () at /lib64/libgio-2.0.so.0 +#4 0x00007f34062086ea in () at /lib64/libglib-2.0.so.0 +#5 0x00007f33fe19b58e in start_thread (arg=<optimized out>) + at pthread_create.c:486 +#6 0x00007f33fe0ca593 in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2 (Thread 0x7f33eb050700 (LWP 10471)): +#0 0x00007f33fe1a5400 in __GI___nanosleep (requested_time=0x7f33eb04d270, remaining=0x7f33eb04d280) at ../sysdeps/unix/sysv/linux/nanosleep.c:28 +#1 0x00007f3406209e17 in g_usleep () at /lib64/libglib-2.0.so.0 +#2 0x0000559b04f7cb80 in call_rcu_thread (opaque=opaque@entry=0x0) + at util/rcu.c:253 +#3 0x0000559b04f6afba in qemu_thread_start (args=<optimized out>) + at util/qemu-thread-posix.c:498 +#4 0x00007f33fe19b58e in start_thread (arg=<optimized out>) + at pthread_create.c:486 +#5 0x00007f33fe0ca593 in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 1 (Thread 0x7f33eb9b42c0 (LWP 10470)): +#0 0x00007f33fe00553f in __GI_raise (sig=sig@entry=6) + at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007f33fdfef895 in __GI_abort () at abort.c:79 +#2 0x00007f33fdfef769 in __assert_fail_base (fmt=0x7f33fe156ea8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x559b050203cf "req->status == -1", file=0x559b050203aa "hw/scsi/scsi-bus.c", line=1374, function=0x559b05020dc0 <__PRETTY_FUNCTION__.32414> "scsi_req_complete") at assert.c:92 +#3 0x00007f33fdffd9f6 in __GI___assert_fail (assertion=assertion@entry=0x559b050203cf "req->status == -1", file=file@entry=0x559b050203aa "hw/scsi/scsi-bus.c", line=line@entry=1374, function=function@entry=0x559b05020dc0 <__PRETTY_FUNCTION__.32414> "scsi_req_complete") at assert.c:101 +#4 0x0000559b04da23c0 in scsi_req_complete (req=<optimized out>, status=<optimized out>) at hw/scsi/scsi-bus.c:1374 +#5 0x0000559b04d9cc60 in scsi_dma_complete_noio (r=0x559b069c3600, ret=<optimized out>) at hw/scsi/scsi-disk.c:281 +#6 0x0000559b04d9cd0f in scsi_dma_complete (opaque=0x559b069c3600, ret=-5) + at hw/scsi/scsi-disk.c:302 +#7 0x0000559b04c91607 in dma_complete (ret=-5, dbs=0x559b07808000) + at dma-helpers.c:116 +#8 0x0000559b04c91607 in dma_blk_cb (opaque=0x559b07808000, ret=-5) + at dma-helpers.c:138 +#9 0x0000559b04ec411e in blk_aio_complete (acb=0x559b07514fa0) + at block/block-backend.c:1345 +#10 0x0000559b04f7e32b in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:116 +#11 0x00007f33fe01b200 in __start_context () + at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +#12 0x00007ffc0896b040 in () +#13 0x0000000000000000 in () + +I bisected this to: + +40dce4ee61c68395f6d463fae792f61b7c003bce is the first bad commit +commit 40dce4ee61c68395f6d463fae792f61b7c003bce +Author: Paolo Bonzini <email address hidden> +Date: Sat Oct 13 11:52:34 2018 +0200 + + scsi-disk: fix rerror/werror=ignore + + rerror=ignore was returning true from scsi_handle_rw_error but the callers were not + calling scsi_req_complete when rerror=ignore returns true (this is the correct thing + to do when true is returned after executing a passthrough command). Fix this by + calling it in scsi_handle_rw_error. + + Signed-off-by: Paolo Bonzini <email address hidden> + +:040000 040000 311386b9b91d77840a849459ab6ae41a37fd7f42 8adcda67d7487bcc18966f096c9923da3b8dc0b9 M hw \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1809075 b/results/classifier/gemma3:12b/device/1809075 new file mode 100644 index 000000000..36f1c1d9d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1809075 @@ -0,0 +1,32 @@ + +Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel + +Whenever capslock is pressed on host, both capslock keycode(0x3a 0xba) and capslock LED keycode(0xfa 0xfa) would be sent to the ps2 keycode stream. + +However, capslock LED is handled by another thread, confirmed by tracing `ps2_write_keyboard` with gdb. The keycode of casplock LED might divide + +For example, I sent AaBb but got ABa. I was using vncdotool, so it equals sending `capslock a capslock a capslock b capslock b`. In ps2_queue, I was expecting `3a fa fa ba 1e 9e 3a fa fa ba 1e 9e 3a fa fa ba 30 b0 3a fa fa ba 30 b0`. But actually once in a while, it might not receive such streams. In one case I got `3a fa fa ba 1e 9e 3a ba 1e fa fa 9e 3a ba 30 b0 3a ba 30 b0 fa fa` + +In this specific example, `a` was lost because LED keycode 'jumps in' its keycode. Kernel event device receives below streams +``` +# /dev/input/event receives what is sent from ps2_queue +# I use cap_1 to show capslock key down +cap_1 led caps_0, # 0x3a 0xfa 0xfa 0xba +a_1 a_0 # 0x1e 0x9e +caps_1 caps_0 # 0x3a 0xba +led # 0x1e 0xfa 0xfa 0x1e (we lost `a` here) +caps_1 caps_0 # 0x3a 0xba +b_1 led b_0 # 0x30 0xfa 0xfa 0xb0 +caps_1 caps_0 # 0x3a 0xba +led b_1 b_0 # 0xfa 0xfa 0x30 0xb0 +``` + +I made sure kernel receives the correct key stream as the qemu ps2_queue sends using /proc, ftrace and dynamic_debug. I explained the details in this [post](https://medium.com/@alapha23/quick-peek-into-kernel-land-keyboard-events-handling-with-ftrace-and-dynamic-debug-24a790056d5a) + +So it seems to be a concurrency issue. + +A hacky path on my mind is to skip all `0xfa` in ps2_queue. But I'm not sure if capslock LED is the only stink bug to our ps2 keycode queue as I've seen other keycodes handled by `ps2_write_keyboard` sent to ps2 queue. + +Another solution might be a memory barrier or a lock. Making key down and key up atomic will prevent another thread modifying the ps2 queue unwantedly. + +What do you think? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1809291 b/results/classifier/gemma3:12b/device/1809291 new file mode 100644 index 000000000..9d7002756 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1809291 @@ -0,0 +1,13 @@ + +SD Card not working in Ubuntu 18.10 (CMD 2,3 timeout). The device worked fine in Ubuntu 18.04 and earlier versions but not in Ubuntu 18.10 + +ARM PL181 MMC card no longer working in qemu-system-arm in Ubuntu 18.10 +The MMC driver code worked fine in Ubuntu 15.10 to 18.04. +The command to run qemu-system-arm is + + qemu-system-arm -M versatilepb -m 256M -sd sdimage -kernel t.bin -serial mon:stdio + +During SDC initialization, SDC commands 2, 3, 9, 13, 7, 16 all timeout, +which cause subsequent read/write commands 17/24 to fail also. + +Tried both ARM versatilepb and realview-pb-a8, realview-pbx-a9 boards: all the same. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1809546 b/results/classifier/gemma3:12b/device/1809546 new file mode 100644 index 000000000..f02d92551 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1809546 @@ -0,0 +1,45 @@ + +Writing a byte to a pl011 SFR overwrites the whole SFR + +The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. + +I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. + +Given: + +pl011_addr: .word 0x10009000 + +The following snippet will be problematic: + + ldr r3, pl011_addr + ldrb r2, [r3, #0x38] // IMSC + mov r2, #0 + orr r2, r2, #0x10 // R2 == 0x10 + strb r2, [r3, #0x38] // Whole word reads correctly after this + ldrb r2, [r3, #0x39] + mov r2, #0 + strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as well + +After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000010 + +After the second strb instruction, the write to 0x10009039 clears the entire word: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000000 + +QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: + +qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio + +Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: + + ldr r3, pl011_addr + mov r2, #0x10 + str r2, [r3, #0x38] + +Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. + +I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1809665 b/results/classifier/gemma3:12b/device/1809665 new file mode 100644 index 000000000..a2530ec04 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1809665 @@ -0,0 +1,31 @@ + +Xbox One controller USB passthrough disconnections and stops + +I can't properly passthrough my Xbox One controller to a virtual machine; it causes USB disconnections on the host, ultimately preventing it to work (at all) on the guest + +I've seen a few other cases reported in other websites, which show the same symptoms: + +- https://www.reddit.com/r/VFIO/comments/97dhbw/qemu_w10_xbox_one_controller +- https://unix.stackexchange.com/questions/452751/how-can-i-pass-through-an-xbox-one-controller-to-a-windows-vm-on-ubuntu + +This is sample: + + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again + libusb: error [_get_usbfs_fd] libusb couldn't open USB device + /dev/bus/usb/003/016: No such file or directory + +I think this is a quite long-standing issue, as I've been experiencing through several versions, including the current one (3.1). + +I can reproduce this 100% of the times, on multiple host O/S distributions (the current one being based on Ubuntu 18.04 x86-64). + +I compile QEMU directly from source, and execute it via commandline; the command is very long, however, the relevant part is standard (I think): + + -usb \ + -device usb-tablet \ + -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ + +The guest is Windows 10 64bit. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1809684 b/results/classifier/gemma3:12b/device/1809684 new file mode 100644 index 000000000..43387b211 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1809684 @@ -0,0 +1,27 @@ + +amdgpu passthrough on POWER9 (ppc64el) not working + +When attempting to pass a Vega 56 GPU to a virtualized guest using QEMU 3.1 on ppc64el (POWER9), the guest is unable to initialize the GPU. Further digging reveals the driver attempting to allocate a large BAR, which then fails: + +[ 6.058544] [drm] PCI I/O BAR is not found. +<snip uninteresting bits> +[ 6.679193] amdgpu 0000:00:03.0: BAR 2: releasing [mem 0x210400000000-0x2104001fffff pref] +[ 6.679306] amdgpu 0000:00:03.0: BAR 0: releasing [mem 0x210200000000-0x2103ffffffff pref] +[ 6.679361] amdgpu 0000:00:03.0: BAR 0: no space for [mem size 0x200000000 pref] +[ 6.679403] amdgpu 0000:00:03.0: BAR 0: failed to assign [mem size 0x200000000 pref] +[ 6.679444] amdgpu 0000:00:03.0: BAR 2: assigned [mem 0x200080200000-0x2000803fffff pref] +[ 6.681420] amdgpu 0000:00:03.0: VRAM: 8176M 0x000000F400000000 - 0x000000F5FEFFFFFF (8176M used) +[ 6.681507] amdgpu 0000:00:03.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF +[ 6.681594] amdgpu 0000:00:03.0: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF +[ 6.681653] [drm] Detected VRAM RAM=8176M, BAR=0M +[ 6.681688] [drm] RAM width 2048bits HBM +[ 6.681885] [TTM] Zone kernel: Available graphics memory: 4176288 kiB +[ 6.681978] [TTM] Zone dma32: Available graphics memory: 2097152 kiB +[ 6.682043] [TTM] Initializing pool allocator +[ 6.682159] [drm] amdgpu: 8176M of VRAM memory ready +[ 6.682249] [drm] amdgpu: 6117M of GTT memory ready. +[ 6.682387] [drm] GART: num cpu pages 8192, num gpu pages 131072 +[ 6.682466] amdgpu 0000:00:03.0: (-22) kernel bo map failed +[ 6.682539] [drm:amdgpu_device_init [amdgpu]] *ERROR* amdgpu_vram_scratch_init failed -22 +[ 6.682592] amdgpu 0000:00:03.0: amdgpu_device_ip_init failed +[ 6.682636] amdgpu 0000:00:03.0: Fatal error during GPU init \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1810 b/results/classifier/gemma3:12b/device/1810 new file mode 100644 index 000000000..0bec1583b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1810 @@ -0,0 +1,192 @@ + +heap-buffer-overflow in esp_do_dma() +Description of problem: +Got a heap-buffer-overflow error when fuzzing the device am53c974. +Steps to reproduce: +Minimized reproducer: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -device \ +am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ +id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest /dev/null\ + -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc03d 0x03000000 +outl 0xc047 0x065a9d80 +outl 0xc00a 0xc10000 +write 0x65a9d 0x1 0x04 +write 0x65a9e 0x1 0x10 +outl 0xc03d 0x03000000 +outl 0xc00a 0xc10000 +outl 0xc00b 0x0800 +outl 0xc00b 0x00 +outl 0xc00b 0x0800 +outl 0xc00b 0x0800 +outl 0xc00b 0x0800 +outl 0xc00b 0x0400 +outl 0xc00b 0x0800 +outl 0xc00b 0x0800 +outw 0xc00b 0x1000 +outw 0xc00b 0x9000 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +[I 0.000000] OPENED +[R +0.022834] outl 0xcf8 0x80001010 +[S +0.022864] OK +OK +[R +0.022874] outl 0xcfc 0xc000 +[S +0.022887] OK +OK +[R +0.022942] outl 0xcf8 0x80001004 +[S +0.022990] OK +OK +[R +0.023028] outw 0xcfc 0x05 +[S +0.023508] OK +OK +[R +0.023518] outl 0xc03d 0x03000000 +[S +0.023527] OK +OK +[R +0.023532] outl 0xc047 0x065a9d80 +[S +0.023537] OK +OK +[R +0.023544] outl 0xc00a 0xc10000 +[S +0.023573] OK +OK +[R +0.023581] write 0x65a9d 0x1 0x04 +[S +0.023891] OK +OK +[R +0.023900] write 0x65a9e 0x1 0x10 +[S +0.023906] OK +OK [R +0.023910] outl 0xc03d 0x03000000 +[S +0.023917] OK +OK +[R +0.023921] outl 0xc00a 0xc10000 +[S +0.023983] OK +OK +[R +0.023581] write 0x65a9d 0x1 0x04 +[S +0.023891] OK +OK +[R +0.023900] write 0x65a9e 0x1 0x10 +[S +0.023906] OK +OK [R +0.023910] outl 0xc03d 0x03000000 +[S +0.023917] OK +OK +[R +0.023921] outl 0xc00a 0xc10000 +[S +0.023983] OK +OK +[R +0.023991] outl 0xc00b 0x0800 +[S +0.023998] OK +OK +[R +0.024002] outl 0xc00b 0x00 +[S +0.024008] OK +OK +[R +0.024014] outl 0xc00b 0x0800 +[S +0.024028] OK +OK +[R +0.024034] outl 0xc00b 0x0800 +[S +0.024040] OK +OK +[R +0.024051] outl 0xc00b 0x0800 +[S +0.024058] OK +OK +[R +0.024065] outl 0xc00b 0x0400 +[S +0.024073] OK +OK +[R +0.024082] outl 0xc00b 0x0800 +[S +0.024089] OK +OK +[R +0.024104] outl 0xc00b 0x0800 +[S +0.024121] OK +OK +[R +0.024133] outw 0xc00b 0x1000 +[S +0.024150] OK +OK +[R +0.024159] outw 0xc00b 0x9000 +================================================================= +==63330==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500020c000 at pc 0x5601fffcf1d4 bp 0x7ffe1920dcf0 sp 0x7ffe1920d4b0 +WRITE of size 32736 at 0x62500020c000 thread T0 + #0 0x5601fffcf1d3 in __asan_memcpy ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 + #1 0x5602015f506b in flatview_read_continue ../softmmu/physmem.c:2726:13 + #2 0x5602015f5ee3 in flatview_read ../softmmu/physmem.c:2762:12 + #3 0x5602015f5bf7 in address_space_read_full ../softmmu/physmem.c:2775:18 + #4 0x560200943ef0 in dma_memory_rw_relaxed ../include/sysemu/dma.h:87:12 + #5 0x560200943ef0 in dma_memory_rw ../include/sysemu/dma.h:130:12 + #6 0x560200943ef0 in pci_dma_rw ../hw/pci/pci_device.h:233:12 + #7 0x560200943ef0 in esp_pci_dma_memory_rw ../hw/scsi/esp-pci.c:283:5 + #8 0x56020092db7e in esp_do_dma ../hw/scsi/esp.c + #9 0x560200935774 in handle_ti ../hw/scsi/esp.c:912:9 + #10 0x560200932db6 in esp_reg_write ../hw/scsi/esp.c:1083:13 + #11 0x56020094574d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9 + #12 0x5602015b5f23 in memory_region_write_accessor ../softmmu/memory.c:493:5 + #13 0x5602015b56aa in access_with_adjusted_size ../softmmu/memory.c:569:18 + #14 0x5602015b4a50 in memory_region_dispatch_write ../softmmu/memory.c + #15 0x5602015fefbf in flatview_write_continue ../softmmu/physmem.c:2653:23 + #16 0x5602015f6463 in flatview_write ../softmmu/physmem.c:2695:12 + #17 0x5602015f6177 in address_space_write ../softmmu/physmem.c:2791:18 + #18 0x5602015a7e99 in cpu_outw ../softmmu/ioport.c:75:5 + #19 0x560200d28daa in qtest_process_command ../softmmu/qtest.c:483:13 + #20 0x560200d2795b in qtest_process_inbuf ../softmmu/qtest.c:788:9 + #21 0x560201b581a6 in fd_chr_read ../chardev/char-fd.c:72:9 + #22 0x7f8fce57e04d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561) + #23 0x560201dc540f in glib_pollfds_poll ../util/main-loop.c:290:9 + #24 0x560201dc540f in os_host_main_loop_wait ../util/main-loop.c:313:5 + #25 0x560201dc540f in main_loop_wait ../util/main-loop.c:592:11 + #26 0x560200d34f76 in qemu_main_loop ../softmmu/runstate.c:732:9 + #27 0x56020173e835 in qemu_default_main ../softmmu/main.c:37:14 + #28 0x7f8fcd3a5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #29 0x5601fff2009d in _start ./qemu-system-x86_64+0x1e9109d) + +0x62500020c000 is located 0 bytes to the right of 4096-byte region [0x62500020b000,0x62500020c000) +allocated by thread T0 here: + #0 0x5601fffd0a0c in posix_memalign ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 + #1 0x560201db83da in qemu_try_memalign ../util/memalign.c:53:11 + #2 0x560201db8762 in qemu_memalign ../util/memalign.c:73:15 + #3 0x5602008c779e in scsi_req_enqueue ../hw/scsi/scsi-bus.c:906:10 + #4 0x56020093bd2f in do_command_phase ../hw/scsi/esp.c:296:15 + #5 0x56020093bd2f in do_cmd ../hw/scsi/esp.c:344:5 + #6 0x560200932911 in esp_reg_write ../hw/scsi/esp.c:1112:13 + #7 0x56020094574d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9 + #8 0x5602015b5f23 in memory_region_write_accessor ../softmmu/memory.c:493:5 + #9 0x5602015b56aa in access_with_adjusted_size ../softmmu/memory.c:569:18 + +SUMMARY: AddressSanitizer: heap-buffer-overflow ./llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy +Shadow bytes around the buggy address: + 0x0c4a800397b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c4a80039800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039850: 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 +==63330==ABORTING +``` diff --git a/results/classifier/gemma3:12b/device/1810975 b/results/classifier/gemma3:12b/device/1810975 new file mode 100644 index 000000000..51e8e03ef --- /dev/null +++ b/results/classifier/gemma3:12b/device/1810975 @@ -0,0 +1,25 @@ + +qemu crashes when using "host" smartcard + +Hello, + +When starting qemu 3.1 (via libvirt) with an "host" smartcard defined, it crashes with: + + + Stack trace of thread 15264: + #0 0x00007f17029ae5f7 __GI___getpriority (libc.so.6) + #1 0x00007f170254ae18 _pt_root (libnspr4.so) + #2 0x00007f1702a86fa3 start_thread (libpthread.so.0) + #3 0x00007f17029b789f __clone (libc.so.6) + + Stack trace of thread 15210: + #0 0x00007f17029b7891 __clone (libc.so.6) + #1 0x0000000000000000 n/a (n/a) + + +Command line: + +qemu-system-x86_64 -enable-kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-win10/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-IBRS,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,ssbd=on,xsaveopt=on,pdpe1gb=on,abm=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 2109c1d6-edb0-4e2e-bd6a-cd7e38d303f2 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,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 ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -device usb-ccid,id=ccid0,bus=usb.0,port=4 -drive file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1 -drive 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 tap,fd=28,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:b4:0f:cc,bus=pci.0,addr=0x3 -device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=0,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=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917007 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1811543 b/results/classifier/gemma3:12b/device/1811543 new file mode 100644 index 000000000..5fb1811b5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1811720 b/results/classifier/gemma3:12b/device/1811720 new file mode 100644 index 000000000..1e90009b8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1811720 @@ -0,0 +1,8 @@ + +storage physical_block_size is restricted to uint16_t + +It is desirable to set -global scsi-hd.physical_block_size=4194304 for RBD-backed storage. + +But unfortunatelly, this values is restricted with uint16_t, i.e. 65536 maximum. + +For example, scsi-hd.discard_granularity=4194304 is not so restricted (and works as expected) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1811758 b/results/classifier/gemma3:12b/device/1811758 new file mode 100644 index 000000000..40ff77177 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1813 b/results/classifier/gemma3:12b/device/1813 new file mode 100644 index 000000000..4e321ba01 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1813 @@ -0,0 +1,113 @@ + +FPE division by zero in scsi_disk_reset() [CVE-2023-42467] +Description of problem: +Got an FPE division by zero error when fuzzing the device am53c974. +Steps to reproduce: +Minimized reproducer for the error: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -device \ +am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ +id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest /dev/null\ + -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc047 0x065a9d01 +write 0x65a9d 0x1 0x15 +write 0x65a9e 0x1 0x10 +write 0x65aa0 0x1 0x08 +write 0x65aa1 0x1 0x0c +write 0x65aa7 0x1 0x01 +outl 0xc03d 0x03000000 +outl 0xc00a 0xc10000 +outl 0xc03d 0x03000000 +outl 0xc00a 0xc10000 +outl 0xc00b 0x9000 +outl 0xc00b 0x0300 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +[I 0.000000] OPENED +[R +0.024387] outl 0xcf8 0x80001010 +[S +0.024420] OK +OK +[R +0.024470] outl 0xcfc 0xc000 +[S +0.024490] OK +OK +[R +0.024513] outl 0xcf8 0x80001004 +[S +0.024521] OK +OK +[R +0.024527] outw 0xcfc 0x05 +[S +0.022723] OK +OK +[R +0.022734] outl 0xc047 0x065a9d01 +[S +0.022742] OK +OK +[R +0.022747] write 0x65a9d 0x1 0x15 +[S +0.022932] OK +OK +[R +0.022941] write 0x65a9e 0x1 0x10 +[S +0.022947] OK +OK +[R +0.022952] write 0x65aa0 0x1 0x08 +[S +0.022958] OK +OK +[R +0.022965] write 0x65aa1 0x1 0x0c +[S +0.022973] OK +OK +[R +0.022983] write 0x65aa7 0x1 0x01 +[S +0.022991] OK +OK +[R +0.023004] outl 0xc03d 0x03000000 +[S +0.023014] OK +OK +[R +0.023021] outl 0xc00a 0xc10000 +[S +0.023048] OK +OK +[R +0.023056] outl 0xc03d 0x03000000 +[S +0.023065] OK +OK +[R +0.023072] outl 0xc00a 0xc10000 +[S +0.023128] OK +OK +[R +0.023141] outl 0xc00b 0x9000 +[S +0.023159] OK +OK +[R +0.023166] outl 0xc00b 0x0300 +../hw/scsi/scsi-disk.c:2351:16: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/scsi-disk.c:2351:16 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==1208622==ERROR: AddressSanitizer: FPE on unknown address 0x558e9c0a9386 (pc 0x558e9c0a9386 bp 0x7ffcc04aaf50 sp 0x7ffcc04aaec0 T0) + #0 0x558e9c0a9386 in scsi_disk_reset ../hw/scsi/scsi-disk.c:2351:16 + #1 0x558e9cf23f23 in resettable_phase_hold ../hw/core/resettable.c + #2 0x558e9cf0a861 in bus_reset_child_foreach ../hw/core/bus.c:97:13 + #3 0x558e9cf23c05 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #4 0x558e9cf21b69 in resettable_assert_reset ../hw/core/resettable.c:60:5 + #5 0x558e9cf217aa in resettable_reset ../hw/core/resettable.c:45:5 + #6 0x558e9c0facd7 in esp_reg_write ../hw/scsi/esp.c:1075:13 + #7 0x558e9c10d74d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9 + #8 0x558e9cd7df23 in memory_region_write_accessor ../softmmu/memory.c:493:5 + #9 0x558e9cd7d6aa in access_with_adjusted_size ../softmmu/memory.c:569:18 + #10 0x558e9cd7ca50 in memory_region_dispatch_write ../softmmu/memory.c + #11 0x558e9cdc6fbf in flatview_write_continue ../softmmu/physmem.c:2653:23 + #12 0x558e9cdbe463 in flatview_write ../softmmu/physmem.c:2695:12 + #13 0x558e9cdbe177 in address_space_write ../softmmu/physmem.c:2791:18 + #14 0x558e9cd70208 in cpu_outl ../softmmu/ioport.c:85:5 + #15 0x558e9c4f0e76 in qtest_process_command ../softmmu/qtest.c:485:13 + #16 0x558e9c4ef95b in qtest_process_inbuf ../softmmu/qtest.c:788:9 + #17 0x558e9d3201a6 in fd_chr_read ../chardev/char-fd.c:72:9 + #18 0x7f974a7c904d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561) + #19 0x558e9d58d40f in glib_pollfds_poll ../util/main-loop.c:290:9 + #20 0x558e9d58d40f in os_host_main_loop_wait ../util/main-loop.c:313:5 + #21 0x558e9d58d40f in main_loop_wait ../util/main-loop.c:592:11 + #22 0x558e9c4fcf76 in qemu_main_loop ../softmmu/runstate.c:732:9 + #23 0x558e9cf06835 in qemu_default_main ../softmmu/main.c:37:14 + #24 0x7f97495f0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #25 0x558e9b6e809d in _start (./qemu-system-x86_64+0x1e9109d) +``` diff --git a/results/classifier/gemma3:12b/device/1815 b/results/classifier/gemma3:12b/device/1815 new file mode 100644 index 000000000..1ce6f2771 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1815413 b/results/classifier/gemma3:12b/device/1815413 new file mode 100644 index 000000000..4a6c130e4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1815445 b/results/classifier/gemma3:12b/device/1815445 new file mode 100644 index 000000000..0d010e6c0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1815445 @@ -0,0 +1,16 @@ + +change and eject commands are not working on an overlay + +From qemu monitor, 'change' and 'eject' commands are not working on a CD overlay. +'info block' returns: + cd0-overlay0: /home/guillaume/test/cd0-overlay0 (qcow2) + Attached to: cd0-device + Removable device: not locked, tray closed + Cache mode: writeback, ignore flushes + Backing file: /home/guillaume/test.iso (chain depth: 1) + +But 'eject cd0-overlay0' returns: + Device 'cd0-overlay0' not found +I also tried 'cd0-device' and 'cd0'. + +Same problem with 'change' command. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1816052 b/results/classifier/gemma3:12b/device/1816052 new file mode 100644 index 000000000..b37e4d611 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1816052 @@ -0,0 +1,72 @@ + +qemu system emulator fails to start if no sound card is present on host + +A plain build from git master at 81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host, with no options passed to configure. + +Trying to launch QEMU on a host with no audio card present: + +# ls /dev/snd/ +seq timer + +It will fail to initialize alsa and abort startup: + +# qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso -m 4000 -vnc 0.0.0.0:1 +ALSA lib confmisc.c:767:(parse_card) cannot find card '0' +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory +ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory +ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory +ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or directory +ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default +alsa: Could not initialize DAC +alsa: Failed to open `default': +alsa: Reason: No such file or directory +ALSA lib confmisc.c:767:(parse_card) cannot find card '0' +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory +ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory +ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory +ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or directory +ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default +alsa: Could not initialize DAC +alsa: Failed to open `default': +alsa: Reason: No such file or directory +init fail +audio: Failed to create voice `pcspk' +qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing audio voice failed + + +git bisect blames this change: + + + commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad) + Author: Gerd Hoffmann <email address hidden> + Date: Thu Jan 24 12:20:55 2019 +0100 + + audio: probe audio drivers by default + + Add the drivers listed in audio_possible_drivers to audio_drv_list, + using the try-* variants. That way the probable drivers are compiled by + default if possible. + + Additioal tweaks: + linux: reorder to: pa alsa sdl oss. + *bsd: drop pa. + + Signed-off-by: Gerd Hoffmann <email address hidden> + Message-id: <email address hidden> + + +This changed our probe order: + + Linux) + - audio_drv_list="oss" + + audio_drv_list="try-pa try-alsa try-sdl oss" + +After some debugging I can see that 'audio_init' successfully initializes the alsa driver. + +When the pcspk devices goes to AUD_open_out though, the alsa driver fails spewing the above text to stderr and thus causes QEMU to fail. + +This looks very much like the ALSA driver in QEMU is broken - audio_init() should not have succeeded unless the ALSA driver knew it could later succesfully honour AUD_open_out. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1816805 b/results/classifier/gemma3:12b/device/1816805 new file mode 100644 index 000000000..47a020d26 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1817525 b/results/classifier/gemma3:12b/device/1817525 new file mode 100644 index 000000000..f736b8457 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1817525 @@ -0,0 +1,79 @@ + +qemu fails to compile on gcc 9 "block/nvme.c:209:22: error: taking address of packed member of 'struct <anonymous>' may result in an unaligned pointer value [-Werror=address-of-packed-member]" + +Issue: +Qemu compilation fails with below error on ppc64le host with gcc 9, repo(https://github.com/dgibson/qemu.git), branch(ppc-for-4.0), Commit (0483e90393bac8546a1fbc95ab912a1e78e92b00) + + CHK version_gen.h + CC block/nvme.o +block/nvme.c: In function ‘nvme_create_queue_pair’: +block/nvme.c:209:22: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 209 | q->sq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale]; + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +block/nvme.c:216:22: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 216 | q->cq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale + 1]; + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/usr/share/avocado-plugins-vt/build/qemu/rules.mak:69: block/nvme.o] Error 1 + + + +$git commit: +commit 0483e90393bac8546a1fbc95ab912a1e78e92b00 (HEAD -> ppc-for-4.0) +Author: Thomas Huth <email address hidden> +Date: Thu Feb 21 12:24:48 2019 +0100 + + hw/ppc: Use object_initialize_child for correct reference counting + + Both functions, object_initialize() and object_property_add_child() increase + the reference counter of the new object, so one of the references has to be + dropped afterwards to get the reference counting right. Otherwise the child + object will not be properly cleaned up when the parent gets destroyed. + Thus let's use now object_initialize_child() instead to get the reference + counting here right. + + Suggested-by: Eduardo Habkost <email address hidden> + Signed-off-by: Thomas Huth <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Cédric Le Goater <email address hidden> + Signed-off-by: David Gibson <email address hidden> + + +Note: Same commit on a different ppc64le host with gcc(8.1.1 20180712) compile without any issue. + +Env: + +Power8 + +#lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 160 +On-line CPU(s) list: 0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152 +Off-line CPU(s) list: 1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79,81-87,89-95,97-103,105-111,113-119,121-127,129-135,137-143,145-151,153-159 +Thread(s) per core: 1 +Core(s) per socket: 5 +Socket(s): 4 +NUMA node(s): 4 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8E (raw), altivec supported +CPU max MHz: 3690.0000 +CPU min MHz: 2061.0000 +L1d cache: 64K +L1i cache: 32K +L2 cache: 512K +L3 cache: 8192K +NUMA node0 CPU(s): 0,8,16,24,32 +NUMA node1 CPU(s): 40,48,56,64,72 +NUMA node16 CPU(s): 80,88,96,104,112 +NUMA node17 CPU(s): 120,128,136,144,152 + +# gcc --version +gcc (GCC) 9.0.1 20190209 (Red Hat 9.0.1-0.4) +Copyright (C) 2019 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +# uname -r +5.0.0-rc7-ge50585e89 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/182 b/results/classifier/gemma3:12b/device/182 new file mode 100644 index 000000000..a06833881 --- /dev/null +++ b/results/classifier/gemma3:12b/device/182 @@ -0,0 +1,2 @@ + +qemu-xhci device should detect if libusb host supports streams diff --git a/results/classifier/gemma3:12b/device/1820686 b/results/classifier/gemma3:12b/device/1820686 new file mode 100644 index 000000000..30520b375 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1820686 @@ -0,0 +1,6 @@ + +risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' + +QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. + +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1821054 b/results/classifier/gemma3:12b/device/1821054 new file mode 100644 index 000000000..cfdd77620 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1821054 @@ -0,0 +1,5 @@ + +qemu segfault error when using pcie to dual pci adapter + +All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor" +I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1824528 b/results/classifier/gemma3:12b/device/1824528 new file mode 100644 index 000000000..d18408bcc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1824528 @@ -0,0 +1,19 @@ + +qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]` + +Qemu compilation fails with below error on ppc64le host with gcc 9(9.0.1 20190328) +repo: https://github.com/qemu/qemu.git +branch: master +commit e1be98540ee672ef93292b65a986055512237c35 + + + CC net/dump.o +hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’: +hw/usb/dev-mtp.c:1708:36: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 1708 | dataset->filename); + | ~~~~~~~^~~~~~~~~~ +cc1: all warnings being treated as errors + CC net/eth.o +make: *** [/home/kvmci/qemu-main/rules.mak:69: hw/usb/dev-mtp.o] Error 1 +make: *** Waiting for unfinished jobs.... + CC net/announce.o \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1824744 b/results/classifier/gemma3:12b/device/1824744 new file mode 100644 index 000000000..5a746ce70 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1824744 @@ -0,0 +1,8 @@ + +ivshmem PCI device exposes wrong endianness on ppc64le + +On a ppc64le host with a ppc64le guest running on QEMU 3.1.0 when an ivshmem device is used, the ivshmem device appears to expose the wrong endianness for the values in BAR 0. + +For example, when the guest is assigned an ivshmem device ID of 1, the IVPosition register (u32, offset 8 in BAR 0) returns 0x1000000 instead of 0x1. I tested on an x86_64 machine and the IVPosition reads 0x1 as expected. + +It seems possible that there's a ppc64*==bigendian assumption somewhere that is erroneously affecting ppc64le. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1826827 b/results/classifier/gemma3:12b/device/1826827 new file mode 100644 index 000000000..4f49f4b7f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1826827 @@ -0,0 +1,56 @@ + +dtc crash; pnv_dt_serial cannot find lpc's phandle + +pnv_dt_serial has a line which is supposed to set the interrupt-parent of the "isa-serial@i3f8" node to the phandle of "lpc@0". + +To that end, it calls fdt_get_phandle as shown below: +_FDT((fdt_setprop_cell(fdt, node, "interrupt-parent", fdt_get_phandle(fdt, lpc_off)))); + +The function fdt_get_phandle fails to find the property "phandle" (or "linux,phandle") for the lpc node. Consequently, pnv_dt_serial sets the interrupt-parent to 0. + + + + + +Now boot the qemu-system-ppc64 powernv machine, and extract the fdt by using the qemu monitor's pmemsave command, taking help of the OPAL firmware's messages to locate the fdt in the physical ram. + +qemu-system-ppc64 -m 1g -machine powernv,num-chips=1 \ +-cpu power9 -smp 2,cores=2,threads=1 -accel tcg,thread=multi \ +-kernel ./vmlinux \ +-append 'disable_radix' \ +-serial mon:stdio -nographic -nodefaults + +The kernel vmlinux contains nothing but a single instruction which loops infintely, so that we can gather OPAL's messages, especially the one below: + +[ 0.168845963,5] INIT: Starting kernel at 0x20000000, fdt at 0x304b0b70 14404 bytes + + + + + +Once the fdt is dumped to a file, run the following: + +'dtc -O dtb -I dts -o out.dts dtb' + + +After a few warnings, the dtc application crashes because an assertion was fired. + +1.dts: Warning (unit_address_vs_reg): /lpcm-opb@6030000000000/lpc@0: node has a unit name, but no reg property +1.dts: Warning (simple_bus_reg): /lpcm-opb@6030000000000/lpc@0: missing or empty reg/ranges property +1.dts: Warning (avoid_unnecessary_addr_size): /ibm,opal: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property +1.dts: Warning (unique_unit_address): /interrupt-controller@0: duplicate unit-address (also used in node /memory@0) +1.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead +dtc: livetree.c:575: get_node_by_phandle: Assertion `generate_fixups' failed. +Aborted (core dumped) + + + +The assertion is fired because get_node_by_phandle receives a phandle value of 0, which is unexpected, unless fixups are needed (They are not, when running the dtc command). + + + + +Back inside pnv_dt_serial, if the line that sets "interrupt-parent" for the serial device node is commented out, the dtc crash is prevented. Looking at hw/ppc/e500.c, it takes care of allocating necessary phandle values in the nodes, so a similar method can be adopted for powernv. + + +The dtb is attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1828508 b/results/classifier/gemma3:12b/device/1828508 new file mode 100644 index 000000000..309864c62 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1828608 b/results/classifier/gemma3:12b/device/1828608 new file mode 100644 index 000000000..7ab30bd4b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1829 b/results/classifier/gemma3:12b/device/1829 new file mode 100644 index 000000000..c4ad59f2b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/183 b/results/classifier/gemma3:12b/device/183 new file mode 100644 index 000000000..d78fabed7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/183 @@ -0,0 +1,2 @@ + +Cannot use usb-host on Mac OS diff --git a/results/classifier/gemma3:12b/device/1831 b/results/classifier/gemma3:12b/device/1831 new file mode 100644 index 000000000..6c6c4e5fb --- /dev/null +++ b/results/classifier/gemma3:12b/device/1831 @@ -0,0 +1,2 @@ + +qemu-system-m68k: ../hw/scsi/scsi-disk.c:557: scsi_write_data: Assertion `r->req.aiocb == NULL' failed. diff --git a/results/classifier/gemma3:12b/device/1831115 b/results/classifier/gemma3:12b/device/1831115 new file mode 100644 index 000000000..90de314de --- /dev/null +++ b/results/classifier/gemma3:12b/device/1831115 @@ -0,0 +1,73 @@ + +qemu 4.0.0 on aarch64: uefi firmware oversize + +I'd like to enable uefi in my virtual machine, however qemu is always showing the same error: qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes +It's clearly impossible to fit a uefi firmware into 786432 bytes. + +Environment: qemu-system-aarch64 with kvm on an amlogic s905d aarch64 dev board, running archlinuxarm, qemu in the repository is compiled with https://download.qemu.org/qemu-4.0.0.tar.xz + +(My AAVMF_CODE.fd and AAVMF_VARS.fd are extracted from debian package qemu-efi-aarch64 0~20181115.85588389-3) + +Below is my libvirt log. + +2019-05-30 15:07:44.216+0000: starting up libvirt version: 5.3.0, qemu version: 4.0.0, kernel: 4.19.46-1-ARCH, hostname: jerry-n1.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-debiantesting \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-debiantesting/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-aarch64 \ +-name guest=debiantesting,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-debiantesting/master-key.aes \ +-machine virt-4.0,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \ +-cpu host \ +-drive file=/opt/ovmf/aarch64/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/var/lib/libvirt/qemu/nvram/debiantesting_VARS.fd,if=pflash,format=raw,unit=1 \ +-m 1024 \ +-overcommit mem-lock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 508d100a-b4e5-4199-9ff9-ac6d40fe2896 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-reboot \ +-boot strict=on \ +-device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ +-device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \ +-device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \ +-device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.3,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \ +-drive file=/mnt/hddp1/jerry/libvirt/aarch64-images/debiantesting.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 \ +-drive file=/mnt/hddp1/jerry/libvirt/aarch64-iso/debian-testing-arm64-netinst.iso,format=raw,if=none,id=drive-scsi0-0-0-1,readonly=on \ +-device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1 \ +-netdev tap,fd=27,id=hostnet0 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d5:28:6d,bus=pci.1,addr=0x0 \ +-chardev pty,id=charserial0 \ +-serial chardev:charserial0 \ +-chardev socket,id=charchannel0,fd=28,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-object rng-random,id=objrng0,filename=/dev/urandom \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.5,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2019-05-30 15:07:44.216+0000: Domain id=2 is tainted: host-cpu +char device redirected to /dev/pts/2 (label charserial0) +2019-05-30T15:07:46.701125Z qemu-system-aarch64: Initialization of device cfi.pflash01 failed: device requires 67108864 bytes, block backend provides 786432 bytes +2019-05-30 15:07:46.779+0000: shutting down, reason=failed +(END) + +# /etc/libvirt/qemu.conf +nvram = [ + "/opt/ovmf/aarch64/AAVMF_CODE.fd:/opt/ovmf/aarch64/AAVMF_VARS.fd" +] \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1833053 b/results/classifier/gemma3:12b/device/1833053 new file mode 100644 index 000000000..7d157eba2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1833053 @@ -0,0 +1,39 @@ + +qemu guest crashes on spice client USB redirected device removal + +Hello, + +I am experiencing guest crashes, which cannot be reproduced at all times, but are pretty frequent (4 out of 5 tries it would crash). The guest crashes when a previously attached USB redirected device through SPICE has been removed by the client. + +Steps to reproduce: +1.) Start windows 10 guest with display driver Spice +2.) Connect to the console with remote-viewer spice://IP:PORT or via virt-viewer (tunnelled through SSH) +3.) Attach a client USB device, for example storage device, iPhone or Android phone +4.) Observe the guest OS detects it and sets it up +5.) Go back to 'USB device selection' and untick the USB device +6.) Observe the guest VM crashed and the below assertion was printed in the qemu log for this virtual machine: + +qemu-system-x86_64: /var/tmp/portage/app-emulation/qemu-4.0.0-r3/work/qemu-4.0.0/hw/usb/core.c:720: usb_ep_get: Assertion `dev != NULL' failed. +2019-06-17 09:25:09.160+0000: shutting down, reason=crashed + + +Versions of related packages on the host: +app-emulation/qemu-4.0.0-r3 +app-emulation/spice-0.14.0-r2:0 +app-emulation/spice-protocol-0.12.14:0 +net-misc/spice-gtk-0.35:0 +Kernel: 5.1.7-gentoo on Intel x86_64 CPU + +Version of the spice-tools on the guest: +virtio-win 0.1-126 +QXL 0.1-21 +mingw-vdagent-win 0.8.0 + +QEMU command line (generated by libvirt): + +/usr/bin/qemu-system-x86_64 -name guest=W10VM,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-41-W10VM/master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_synic,hv_stimer -m 4500 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid b39afae2-5085-4659-891c-b3c65e65af2e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-hpet -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/libvirt/images/W10VM.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,cache=unsafe,discard=unmap,detect-zeroes=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-cache=on -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:f6:21,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=30,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -spice port=5901,addr=0.0.0.0,seamless-migration=on -device qxl-vga,id=video0,ram_size=134217728,vram_size=134217728,vram64_size_mb=0,vgamem_mb=64,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=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +I have attempted to collect a backtrace, but will need direction as I am not sure on which thread to listen and where to set the breakpoint, 'thread apply all backtrace' does not seem to work well with the qemu process... + +Thank you \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1833101 b/results/classifier/gemma3:12b/device/1833101 new file mode 100644 index 000000000..875052706 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1833101 @@ -0,0 +1,42 @@ + +vexpress-a9 (but not -a15) creates two pl111 LCDs due to duplicate sysbus_create_simple("pl111", ...) calls + +Hi, + +Just a small report that (12ec8bd is current master) + +https://github.com/qemu/qemu/blob/12ec8bd/hw/arm/vexpress.c#L652: + + ... + vexpress_common_init() { + ... + sysbus_create_simple("pl111", map[VE_CLCD], pic[14]); + ... + ... + +and + +https://github.com/qemu/qemu/blob/12ec8bd/hw/arm/vexpress.c#L304: + + ... + a9_daughterboard_init() { + ... + sysbus_create_simple("pl111", 0x10020000, pic[44]); + ... + ... + +result in two LCD panels when using vexpress-a9. + +vexpress-a15 does not appear to be affected (my -a9 kernel does not work with it, but I see only one pl111 created). + +Understandably (but still annoyingly), -nodefaults has no effect. + +This bug is most evident when using SDL (so I can use ",frame=off"), which dumps two top-level windows onto the screen. GTK hides this because, coincidentally, the pl111 that ends up being used is the one that is selected (possibly the one created last?), relegating this to an obscure glitch only noticeable if you scrutinize the menu. + +This is a bugreport as opposed to a pull request as I have no idea which call to remove - and complete ignorance of the potential housekeeping and consideration that may be warranted first. + +FWIW, a simple testcase can be made with the vmlinuz from https://people.debian.org/~aurel32/qemu/armhf/ and + +qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -nodefaults -sdl + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1835865 b/results/classifier/gemma3:12b/device/1835865 new file mode 100644 index 000000000..a3d7fc6c0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1835865 @@ -0,0 +1,47 @@ + +piix crashes on mips when accessing acpi-pci-hotplug + +$ qemu-system-mips --version +QEMU emulator version 4.0.50 (v4.0.0-1975-gf34edbc760) + +$ qemu-system-mips -machine malta -bios /dev/null -nodefaults -monitor stdio -S +(qemu) o 0xaf00 0 +qemu-system-mips: hw/acpi/cpu.c:197: cpu_hotplug_hw_init: Assertion `mc->possible_cpu_arch_ids' failed. +Aborted (core dumped) + +(gdb) bt +#0 0x00007f6fd748957f in raise () at /lib64/libc.so.6 +#1 0x00007f6fd7473895 in abort () at /lib64/libc.so.6 +#2 0x00007f6fd7473769 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007f6fd7481a26 in .annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x00005646d58ca7bd in cpu_hotplug_hw_init (as=0x5646d6ae3300, owner=0x5646d6fd5b10, state=0x5646d6fd7a30, base_addr=44800) at hw/acpi/cpu.c:197 +#5 0x00005646d58c5284 in acpi_switch_to_modern_cphp (gpe_cpu=0x5646d6fd7910, cpuhp_state=0x5646d6fd7a30, io_port=44800) at hw/acpi/cpu_hotplug.c:107 +#6 0x00005646d58c3431 in piix4_set_cpu_hotplug_legacy (obj=0x5646d6fd5b10, value=false, errp=0x5646d61cdb28 <error_abort>) at hw/acpi/piix4.c:617 +#7 0x00005646d5b00c70 in property_set_bool (obj=0x5646d6fd5b10, v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", opaque=0x5646d707d110, errp=0x5646d61cdb28 <error_abort>) at qom/object.c:2076 +#8 0x00005646d5afeee6 in object_property_set (obj=0x5646d6fd5b10, v=0x5646d7697d30, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 <error_abort>) at qom/object.c:1268 +#9 0x00005646d5b01fb8 in object_property_set_qobject (obj=0x5646d6fd5b10, value=0x5646d75b5450, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 <error_abort>) at qom/qom-qobject.c:26 +#10 0x00005646d5aff1cb in object_property_set_bool (obj=0x5646d6fd5b10, value=false, name=0x5646d5cf3a90 "cpu-hotplug-legacy", errp=0x5646d61cdb28 <error_abort>) at qom/object.c:1334 +#11 0x00005646d58c4fce in cpu_status_write (opaque=0x5646d6fd7910, addr=0, data=0, size=1) at hw/acpi/cpu_hotplug.c:44 +#12 0x00005646d569c707 in memory_region_write_accessor (mr=0x5646d6fd7920, addr=0, value=0x7ffc18053068, size=1, shift=0, mask=255, attrs=...) at memory.c:503 +#13 0x00005646d569c917 in access_with_adjusted_size (addr=0, value=0x7ffc18053068, size=1, access_size_min=1, access_size_max=4, access_fn=0x5646d569c61e <memory_region_write_accessor>, mr=0x5646d6fd7920, attrs=...) + at memory.c:569 +#14 0x00005646d569f8f3 in memory_region_dispatch_write (mr=0x5646d6fd7920, addr=0, data=0, size=1, attrs=...) at memory.c:1497 +#15 0x00005646d563e5c5 in flatview_write_continue (fv=0x5646d751b000, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4, addr1=0, l=1, mr=0x5646d6fd7920) at exec.c:3324 +#16 0x00005646d563e70a in flatview_write (fv=0x5646d751b000, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3363 +#17 0x00005646d563ea0f in address_space_write (as=0x5646d618abc0 <address_space_io>, addr=44800, attrs=..., buf=0x7ffc180531d4 "", len=4) at exec.c:3453 +#18 0x00005646d5696ee5 in cpu_outl (addr=44800, val=0) at ioport.c:80 +#19 0x00005646d57585d0 in hmp_ioport_write (mon=0x5646d6bc70e0, qdict=0x5646d6cf7140) at monitor/misc.c:1058 +#20 0x00005646d5a77b99 in handle_hmp_command (mon=0x5646d6bc70e0, cmdline=0x5646d6bc2542 "0xaf00 0") at monitor/hmp.c:1082 +#21 0x00005646d5a7540a in monitor_command_cb (opaque=0x5646d6bc70e0, cmdline=0x5646d6bc2540 "o 0xaf00 0", readline_opaque=0x0) at monitor/hmp.c:47 +#22 0x00005646d5c71450 in readline_handle_byte (rs=0x5646d6bc2540, ch=13) at util/readline.c:408 +#23 0x00005646d5a7858f in monitor_read (opaque=0x5646d6bc70e0, buf=0x7ffc180533d0 "\rtc\327FV", size=1) at monitor/hmp.c:1312 +#24 0x00005646d5bc8d17 in qemu_chr_be_write_impl (s=0x5646d6add000, buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:177 +#25 0x00005646d5bc8d7b in qemu_chr_be_write (s=0x5646d6add000, buf=0x7ffc180533d0 "\rtc\327FV", len=1) at chardev/char.c:189 +#26 0x00005646d5bcb6bf in fd_chr_read (chan=0x5646d6a80d60, cond=G_IO_IN, opaque=0x5646d6add000) at chardev/char-fd.c:68 +#27 0x00005646d5bec485 in qio_channel_fd_source_dispatch (source=0x5646d765a480, callback=0x5646d5bcb561 <fd_chr_read>, user_data=0x5646d6add000) at io/channel-watch.c:84 +#28 0x00007f6fd9c1606d in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#29 0x00005646d5c5323a in glib_pollfds_poll () at util/main-loop.c:213 +#30 0x00005646d5c532b4 in os_host_main_loop_wait (timeout=29821719) at util/main-loop.c:236 +#31 0x00005646d5c533b9 in main_loop_wait (nonblocking=0) at util/main-loop.c:512 +#32 0x00005646d581d1a1 in main_loop () at vl.c:1791 +#33 0x00005646d582485f in main (argc=11, argv=0x7ffc18054868, envp=0x7ffc180548c8) at vl.c:4473 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1836855 b/results/classifier/gemma3:12b/device/1836855 new file mode 100644 index 000000000..432bc34f7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1836855 @@ -0,0 +1,33 @@ + +virtio_scsi_ctx_check failed when detach virtio_scsi disk + +I found a problem that virtio_scsi_ctx_check failed when detaching virtio_scsi disk. The bt is below: + +(gdb) bt +#0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +#1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +#2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +#5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +#6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +#7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +#8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +#9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +#10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +#11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +#12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +#13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +#14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 + +assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. + +I think this patch (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) introduce this problem. + +commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back to main AioContext on unplug. It set the AioContext of + +SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContext. Is this a bug? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1838569 b/results/classifier/gemma3:12b/device/1838569 new file mode 100644 index 000000000..9386f8e36 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1838569 @@ -0,0 +1,25 @@ + +virtio-balloon change breaks post 4.0 upgrade + +We upgraded the libvirt UCA packages from 3.6 to 4.0 as part of a queens upgrade and noticed that +virtio-ballon is broken when instances live migrate (started with a prior 3.6 version) with: + + +2019-07-24T06:46:49.487109Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control +2019-07-24T06:47:22.187749Z qemu-system-x86_64: VQ 2 size 0x80 < last_avail_idx 0xb57 - used_idx 0xb59 +2019-07-24T06:47:22.187768Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2019-07-24T06:47:22.187771Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' +2019-07-24T06:47:22.188194Z qemu-system-x86_64: load of migration failed: Operation not permitted +2019-07-24 06:47:22.430+0000: shutting down, reason=failed + +This seem to be the exact problem as reported by https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02228.html + +Listed the packages which changed: + +Start-Date: 2019-07-06 06:40:55 +Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install libvirt-bin python-libvirt qemu qemu-utils qemu-system qemu-system-arm qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-system-misc qemu-block-extra qemu-utils qemu-user qemu-kvm +Install: librdmacm1:amd64 (17.1-1ubuntu0.1~cloud0, automatic), libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.10~cloud0, automatic), ipxe-qemu-256k-compat-efi-roms:amd64 (1.0.0+git-20150424.a25a16d-0ubuntu2~cloud0, automatic) +Upgrade: qemu-system-mips:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-misc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-ppc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), python-libvirt:amd64 (3.5.0-1build1~cloud0, 4.0.0-1~cloud0), qemu-system-x86:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-clients:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-user:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-bin:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-utils:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon-system:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-sparc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-user-binfmt:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-kvm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt0:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-arm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-block-extra:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-common:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0) +End-Date: 2019-07-06 06:41:08 + +At this point the instances would have to be hard rebooted or stopped/started to fix the issue for future live migration attemps \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1839060 b/results/classifier/gemma3:12b/device/1839060 new file mode 100644 index 000000000..3fa363b50 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1839428 b/results/classifier/gemma3:12b/device/1839428 new file mode 100644 index 000000000..f16545d4c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1839428 @@ -0,0 +1,39 @@ + + qemu core dumped when repeat "system_reset" multiple times during guest boot + +commit 864ab314f1d924129d06ac7b571f105a2b76a4b2 (HEAD, tag: v4.1.0-rc4, origin/master, origin/HEAD, master) +Test arch:x86 and power + +Steps: +1.Boot up guest with command +power cmdline: +/usr/libexec/backup/qemu-kvm \ + -smp 8 \ + -m 4096 \ + -nodefaults \ + -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 \ + -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ + -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off \ + -device spapr-vty,id=serial111,chardev=serial_id_serial0 \ + -mon chardev=serial_id_serial0,mode=readline \ +x86 cmdline: +/usr/libexec/qemu-kvm \ + -m 4096 -smp 8 \ + -boot menu=on \ + -device virtio-blk-pci,id=image1,drive=drive_image1\ + -drive file=rhel77-64-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ + -vga std \ + -vnc :9 \ + -nographic \ + -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \ + -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ + +2.when guest start to boot up kernel(when no output infomation),run hmp command "system_reset" + + +Result: + +Sometimes,qemu core dumped with error as following: +system_reset +(qemu) qemu-system-ppc64: /root/qemu/hw/virtio/virtio.c:225: vring_get_region_caches: Assertion `caches != NULL' failed. +b.sh: line 11: 73679 Aborted (core dumped) /usr/local/bin/qemu-system-ppc64 -enable-kvm -smp 8 -m 4096 -nodefaults -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off -device spapr-vty,id=serial111,chardev=serial_id_serial0 -mon chardev=serial_id_serial0,mode=readline \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1842530 b/results/classifier/gemma3:12b/device/1842530 new file mode 100644 index 000000000..0d3dc0ccc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1842530 @@ -0,0 +1,62 @@ + +ich6 and ich9 sound card has noisy（murmur） + +[root@localhost1 qemu]# lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 6 +On-line CPU(s) list: 0-5 +Thread(s) per core: 1 +Core(s) per socket: 6 +Socket(s): 1 +NUMA node(s): 1 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 158 +Model name: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz +Stepping: 10 +CPU MHz: 899.951 +CPU max MHz: 4000.0000 +CPU min MHz: 800.0000 +BogoMIPS: 5616.00 +Virtualization: VT-x +L1d cache: 32K +L1i cache: 32K +L2 cache: 256K +L3 cache: 9216K +NUMA node0 CPU(s): 0-5 +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 aperfmperf eagerfpu 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 epb intel_pt ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp spec_ctrl intel_stibp flush_l1d + + +[root@localhost1 qemu]# lsb_release -a +LSB Version: :core-4.1-amd64:core-4.1-noarch +Distributor ID: CentOS +Description: CentOS Linux release 7.6.1810 (Core) +Release: 7.6.1810 +Codename: Core + +Installed as Virtualization Server (qemuV1.5)； +create win7-32 or 64 GuestOS by virt-manager，and select default sound card ich6； + +<graphics type='spice' autoport='yes'> + <listen type='address'/> + <image compression='off'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + + +but obvious noise found when login guest os to play music. :( + +And the problem remains after I update qemu to 2.12.0-18 , 3.1.0 &etc. + + +[root@localhost1 qemu]# /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 3.1.0 +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1842916 b/results/classifier/gemma3:12b/device/1842916 new file mode 100644 index 000000000..3ed00b02b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1842916 @@ -0,0 +1,4 @@ + +[18.04 FEAT] Enhanced Hardware Support - Finalize Naming + +This feature request will provide the final naming of the next machine \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1843 b/results/classifier/gemma3:12b/device/1843 new file mode 100644 index 000000000..c9e2d50ca --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1843651 b/results/classifier/gemma3:12b/device/1843651 new file mode 100644 index 000000000..689a82fff --- /dev/null +++ b/results/classifier/gemma3:12b/device/1843651 @@ -0,0 +1,81 @@ + +m68k fpu bug + +On gcc123 cfarm machine, +I was testing m68k executables generated by Free Pascal Compiler. + +muller@gcc123:~/pas/check$ cat inf.pp +function get_double(x : double):double; + begin + get_double:=x; + end; + + +var + y : double; + py : pbyte; + i : byte; +begin + y:=1.0/0.0; + py:=@y; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; + y:=get_double(y)+1; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; +end. +muller@gcc123:~/pas/check$ ppc68k inf +Free Pascal Compiler version 3.3.1-r20:42973M [2019/09/11] for m68k +Copyright (c) 1993-2019 by Florian Klaempfl and others +Target OS: Linux for m68k +Compiling inf.pp +Assembling program +Linking inf +33 lines compiled, 0.1 sec +muller@gcc123:~/pas/check$ ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ qemu-m68k ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k ./inf +qemu-m68k qemu-m68k-fixed +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k-fixed ./inf +big endian y=7FF0000000000000 +big endian y=7FF0000000000000 + +~/sys-root/bin/qemu-m68k is 4.1.0 release, +~/sys-root/bin/qemu-m68k-fixed is the same source with a unique change: + +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h:214:#if defined(TARGET_M68K) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-215-#define floatx80_infinity_low LIT64(0x0000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-216-#else +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-217-#define floatx80_infinity_low LIT64(0x8000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-218-#endif + +the M68K branch value is set to the same value as the other branch. + +The problem of the M68K specific floatx86_infinity_low values +is that is enters in conflict with +muller@gcc123:~/pas/check$ grep -nA6 invalid_enc /home/muller/gnu/qemu/qemu-4.1.0/include/fpu/softfloat.h +752:static inline bool floatx80_invalid_encoding(floatx80 a) +753-{ +754- return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0; +755-} + +And thus the m68k variant of floatx80 representing +Infinity is +considered as an invalid encoding, and thus converted into a NaN 7FFFFFFFFFFFFFFF \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1843711 b/results/classifier/gemma3:12b/device/1843711 new file mode 100644 index 000000000..e23e49a1a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1843711 @@ -0,0 +1,12 @@ + +qemu-xhci device should detect if libusb host supports streams + +When using USB passthrough with the qemu-xhci (and nec-usb-xhci), streams are enabled by default, but if the host xHCI controller doesn't support them, it will trigger hard-to-debug UAS guest errors. + +This should be possible to detect since the kernel returns ENOSYS (errno 38) when xhci host controller does not support streams: + libusb: error [do_streams_ioctl] streams-ioctl failed error -1 errno 38 + qemu: libusb_alloc_streams: -99 [OTHER] + +Maybe libusb should return a dedicated error instead of LIBUSB_ERROR_OTHER in this case, but qemu does not handle any other error code anyway. + +Just trying to enable streams before enabling them in qemu should do it. I don't know if it should be done in hcd-xhci.c, host-libusb.c or elsewhere, but this would be detectable at launch instead of a static option true/false, maybe a ternary with auto would be better. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1843795 b/results/classifier/gemma3:12b/device/1843795 new file mode 100644 index 000000000..4f1078ee9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1843795 @@ -0,0 +1,32 @@ + +'mtfsf' instruction can clear FI incorrectly + +Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: +-- + fpscr.ll = 0x1fffffff; + __builtin_mtfsf (0b11111111, fpscr.d); + fpscr.d = __builtin_mffs (); +-- + +On POWER9 hardware: +mffs : FPSCR = 0x000000007ffff7ff + +On qemu (git master; "-cpu POWER9"): +-- +$ ./mtfsf +mffs : FPSCR = 0x000000007ffdffff +-- + +Two differences: +bit 52: "reserved", so maybe a "don't care" case +bit 46: "FI" + +$ git log -1 master +commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 +Merge: 019217c 2531164 +Author: Peter Maydell <email address hidden> +Date: Mon Sep 9 09:48:34 2019 +0100 + +I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ + +Test attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1844644 b/results/classifier/gemma3:12b/device/1844644 new file mode 100644 index 000000000..1f9b3757b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1844644 @@ -0,0 +1,7 @@ + +Compiler warnings using MSVC + +The following line of code results in an implicit truncation of an uint16_t value to an uint8_t variable, which triggers a compiler warning in MSVC : https://github.com/qemu/qemu/blob/f8c3db33a5e863291182f8862ddf81618a7c6194/hw/usb/dev-hub.c#L387 +(Two lines down, the same thing happens.) + +This warning can be silenced by doing an explicit truncation, for example by a casting the value explicitly to uint8_t type, or by anding the value with 0xFF. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1846 b/results/classifier/gemma3:12b/device/1846 new file mode 100644 index 000000000..f307705e8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1846 @@ -0,0 +1,26 @@ + +Regression in q35 avocado tests due to fix for misaligned IO access +Description of problem: +Generally I'm seeing intermittent hangs, somewhere after the clock initialisation. + +``` +[ 4.137020] ALSA device list: +[ 4.137861] No soundcards found. +[ 4.634128] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 +[ 24.085574] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: +[ 24.085712] rcu: 0-...!: (0 ticks this GP) idle=4d18/0/0x0 softirq=54/54 fqs=0 (false positive?) +[ 24.085712] (detected by 1, t=21004 jiffies, g=-1003, q=2151 ncpus=2) +[ 24.085712] Sending NMI from CPU 1 to CPUs 0: +[ 4.647507] NMI backtrace for cpu 0 +[ 4.647507] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.11 #5 +[ 4.647507] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 4.647507] RIP: 0010:amd_e400_idle+0x39/0x40 +[ 4.647507] Code: 00 e8 fb ab 0d 00 eb 07 0f 00 2d c2 7d 1d 01 fb f4 fa 31 ff e8 e8 ab 0d 00 fb c3 cc cc cc cc eb 07 0f 00 2d a9 7d 1d 01 fb f4 <c3> cc cc cc cc 66 90 bf +01 00 00 00 e8 a6 e4 06 00 65 48 8b 04 25 +``` + +In avocado the hang generally times out and the test fails. +Steps to reproduce: +See above command line. It's racy. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1846451 b/results/classifier/gemma3:12b/device/1846451 new file mode 100644 index 000000000..fa423ffa5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1846451 @@ -0,0 +1,19 @@ + +K800 keyboard no longer works when attached to a VM + +I use Logitech K800 keyboard which is connected to a PC through Logitech unifying receiver. In order to control my windows VM i attach unifying receiver USB device to a VM using "virsh attach-device VM-Name ./device.xml". Device ID as seen in lsusb is 046d:c52b. + +As of v4.1.0 keyboard no longer works when attached to a windows VM. When attached receiver is still at least partially functional. Logitech pairing utility properly displays paired keyboard, pressing buttons on the keyboard shows changing indicator icon in pairing utility. Pairing and unpairing works. Pressing keys however fails to register any key presses. + +Downgrading to v4.0.0 fixes the issue. + +device.xml used to attach USB device: +``` +<hostdev mode='subsystem' type='usb'> + <source> + <vendor id='0x046d'/> + <product id='0xc52b'/> + </source> +</hostdev> + +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1850570 b/results/classifier/gemma3:12b/device/1850570 new file mode 100644 index 000000000..5b4e34018 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1850570 @@ -0,0 +1,38 @@ + +Cannot use usb-host on Mac OS + +Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives these errors and the drive does not show up. Also, when Qemu is starting the drive ejects and remounts twice. Qemu built with ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl --disable-cocoa --enable-sdl-image. + +qemu-system-i386 image.qcow -usb -device usb-kbd -device usb-host,vendorid=0x0781,productid=0x5571 +libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1851547 b/results/classifier/gemma3:12b/device/1851547 new file mode 100644 index 000000000..087a9807f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1851547 @@ -0,0 +1,21 @@ + +qemu 4 crashes with this parameter attached -usb -device usb-host,hostbus=1,hostaddr=7 \ + +Hello. + +qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to 19.10 and qemu from 3 to 4,as you can see below. what can I do ? + +root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot-OS-HSP2.sh + +----> qemu-system-x86_64: /build/qemu-UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev != NULL" non riuscita. + +./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu-system-x86_64 -enable-kvm -m 16000 -cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none -device vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device vfio-pci,host=01:00.1,bus=pcie.0 -device vfio-pci,host=01:00.2,bus=pcie.0 -device vfio-pci,host=01:00.3,bus=pcie.0 -usb -device usb-host,hostbus=1,hostaddr=7 -drive if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2 -device ich9-ahci,id=sata -drive id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2' -device ide-hd,bus=sata.2,drive=Clover -device ide-hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide-hd,bus=sata.4,drive=BsdHDD -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio + +It seems that this line is not good anymore (it worked with qemu 3.x) : + +-usb -device usb-host,hostbus=1,hostaddr=7 \ + +when I removed it,it works. But I need that. With what can I change it ? You can reproduce that upgrading ubuntu 19.04 to 19.10 because in that way also qemu will be upgraded from 3 to 4. These are the packages that I'm using : + +root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version +QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1851972 b/results/classifier/gemma3:12b/device/1851972 new file mode 100644 index 000000000..4e764352e --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1853898 b/results/classifier/gemma3:12b/device/1853898 new file mode 100644 index 000000000..6c9884053 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1853898 @@ -0,0 +1,25 @@ + +qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed. + +While experimenting with blkdebug I can consistently hit this assertion in lsi53c895a.c. + +Using locally built from master, commit: 2061735ff09f9d5e67c501a96227b470e7de69b1 + +Steps to reproduce + +$ qemu-img create -f raw empty.raw 8G +$ sudo losetup -f --show empty.raw +$ sudo mkfs.ext3 /dev/loop0 +$ sudo losetup -D + +$ cat blkdebug.conf +[inject-error] +event = "read_aio" +errno = "5" + +$ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic user,ipv6=off,model=e1000,hostfwd=tcp::2222-:22,net=172.16.0.0/255.255.255.0 -device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678 -drive if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw -cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk + +Initiate install from cdrom ISO image results in: + +qemu-system-x86_64: /builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed. +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1856399 b/results/classifier/gemma3:12b/device/1856399 new file mode 100644 index 000000000..8e40c477e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1856399 @@ -0,0 +1,20 @@ + +Intel GVT-g works in X11, segfaults in wayland + +Hello, + +I am using an uptodate Arch Linux 64bit with qemu version 4.2.0, but the problem was also present in older versions. The problem occurs with Linux 5.4 and 4.19. +The problem also occurs with Debian as guest. I am running sway. +If I provide -vga std, then qemu works fine until I use the qemu window to switch to the vfio-pci device. There are no problems under X11/xwayland at all. + + +Commandline: +qemu-system-x86_64 + -enable-kvm + -cpu host + -smp 2 + -m 8192 + -display gtk,gl=on + -device vfio-pci,sysfsdev=/sys/devices/pci0000:00/0000:00:02.0/[ID]/,x-igd-opregion=on,display=on + -cdrom archlinux-2019.11.01-x86_64.iso + -vga none \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1856724 b/results/classifier/gemma3:12b/device/1856724 new file mode 100644 index 000000000..3ab599f31 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1856724 @@ -0,0 +1,19 @@ + +SB.PCI0.SMB0 device drivers unavailable + +QEMU 4.2 introduces new device with this code: + +static void build_smb0(Aml *table, I2CBus *smbus, int devnr, int func) +{ + Aml *scope = aml_scope("_SB.PCI0"); + Aml *dev = aml_device("SMB0"); + + aml_append(dev, aml_name_decl("_HID", aml_eisaid("APP0005"))); + aml_append(dev, aml_name_decl("_ADR", aml_int(devnr << 16 | func))); + build_acpi_ipmi_devices(dev, BUS(smbus), "\\_SB.PCI0.SMB0"); + aml_append(scope, dev); + aml_append(table, scope); +} + +It is detected by Windows 10 as 'Unknown Device' and there is no driver available. +Please provide a working Windows driver or give ability to disable this device. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1856834 b/results/classifier/gemma3:12b/device/1856834 new file mode 100644 index 000000000..6abf437e0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1856834 @@ -0,0 +1,28 @@ + +PCI broken in qemu ppc e500 in v2.12.0 and other versions + +The same qemu -M mpc... command that works on qemu-system-ppc version 2.8.0 freezes guest on bootup and shows error for qemu-system-ppc version 4.2.0release and 4.19dirtygit: + +qemu-system-ppc: virtio-blk failed to set guest notifier (-24), ensure -accel kvm is set. +qemu-system-ppc: virtio_bus_start_ioeventfd: failed. Fallback to userspace (slower). + +ends/freezes at: +nbd: registered device at major 43 + vda: + +I'm using -drive file=/home/me/rawimage.dd,if=virtio and works fine in version 2.8.0 installed with apt-get install (Ubuntu 17.04) and also with 2.8.0 official release from git/github that I compiled/built myself. But both of the newer releases fail on the same exact machine same config. + +I also noticed that qemu-2.8.0 was fine with mtd but the newer ones I tried weren't, ie gave +qemu-system-ppc: -drive if=mtd: machine type does not support if=mtd,bus=0,unit=0 +(but I removed -drive if=mtd since wasn't using it anyway) + +I also tried on windows but I think virtio doesn't work on windows hosts at all? On windows host it fails the same way, even version 2.12 as well as 4.1.10... + +used: +./configure --prefix=/opt/... --enable-fdt --enable-kvm --enable-debug + +(basically all steps the same on same exact system same config, yet 2.8.0 works fine whether apt-get installed or built from source while the others I built, 4.19/4.2.0 or 2.12/4.1.10(win) don't.) + +In case newer qemu versions act weird on various kernels, I did try with both vmlinuz-4.10.0-19-generic and vmlinuz-4.13.12-041312-generic (I didn't compile them but I can provide config-..files) +tx + ecs \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1858 b/results/classifier/gemma3:12b/device/1858 new file mode 100644 index 000000000..655b7ad25 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1858 @@ -0,0 +1,11 @@ + +Block device read operation misses one byte(8 bit) per chip per SPI transaction +Description of problem: +Block device Micron m25qu02gcbb (hw/block/m25p80.c) is emulated by the two -drive files. For block device read operation, device driver from Windriver vxWorks issues SPI commands. For read SPI command( 0x6b ) from device driver, there is a data length to be read is specified. For each SPI command call, m25p80_transfer8(SSISlave *ss, uint32_t tx) from hw/block/m25p80.c is called and read byte is returned to guest OS. It is observed that for more than one sequential SPI read commmands, first byte from the next read block is not returned back to guest OS. Traces within m25p80.c shows that all the data bytes are read however, first byte from the next read block is missing at guest OS. + +drive file content: 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 +SPI read command is set to read 4 bytes in one transaction, two transactions are needed from guest OS to read the entire data. +trace_m25p80_read_byte() shows that all bytes are read at m25p80_transfer8() call. +At guest OS following is received: 0x0 0x1 0x2 0x3 0x5 0x6 0x7 0x8 (Missing first byte of the second transaction, 0x4) +Additional information: +Windriver is a proprietary OS so I can't attach the .bin files. However, any other guest OS should be able to demostrate this behavior. guest OS device driver is reading without errors on an actual Micron QSPI device. diff --git a/results/classifier/gemma3:12b/device/1859359 b/results/classifier/gemma3:12b/device/1859359 new file mode 100644 index 000000000..5def46baf --- /dev/null +++ b/results/classifier/gemma3:12b/device/1859359 @@ -0,0 +1,28 @@ + +xHCI and event ring handling + +I believe that the Event Ring handling in QEMU is not correct. For example, an Event Ring may have multiple segments. However, the code in xhci_write_event() (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l645), starting with line 668, seems to only support a single segment. + +Also, QEMU is sending a spurious interrupt after the Guest writes to the ERDP register due to the fact that the address written does not match the current index. This is because the index is incremented after sending the event. The xHCI specification states in section 5.5.2.3.3 "When software finishes processing an Event TRB, it will write the address of that Event TRB to the ERDP." + +Since xhci_write_event() has already incremented the index pointer (intr->er_ep_idx), the check at line 3098 (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3090) no longer is valid. + +I have not studied QEMU's code enough yet to offer a patch. However, this should be a simple fix. + +intr->er_ep_idx++; +if (intr->er_ep_idx >= intr->er_table[intr->er_segment].er_size) { + intr->er_ep_idx = 0; + intr->er_segment++; + if (intr->er_segment >= intr->er_table_size) { + intr->er_segment = 0; + intr->er_pcs = !intr->er_pcs; + } +} + +Being sure to incorporate this new segment member into the above code (possibly as shown) as well as change the lines at 665 to use the new segment member of the structure, and of course in the initialization portion of the event ring. + +As for the spurious interrupt at line 3101, a new member will need to be added to the code to keep track of the last inserted ED (TRB) into the Event Ring and then of course checking against this new member, not the now newly incremented member. + +I have sent an email to the author listed at the top of the file as well, not sure if this is proper bug reporting etiquette or not. + +Thank you. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1859713 b/results/classifier/gemma3:12b/device/1859713 new file mode 100644 index 000000000..302360357 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1859713 @@ -0,0 +1,26 @@ + +ARM v8.3a pauth not working + +Host: Ubuntu 19.10 - x86_64 machine +QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master) + +ARMV8.3 pauth is not working well. + +With a test code containing two pauth instructions: + - paciasp that sign LR with A key and sp as context; + - autiasp that verify the signature. + +Test: + - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664) + +Expected: + - autiasp places an invalid pointer in LR + +Result: + - autiasp successfully auth the pointer and places 0x0400660 in LR. + +Further explanations: + Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating. + With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + Values of top_bit and bottom_bit are strictly the same and it should not. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1861458 b/results/classifier/gemma3:12b/device/1861458 new file mode 100644 index 000000000..8a131b412 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1861562 b/results/classifier/gemma3:12b/device/1861562 new file mode 100644 index 000000000..74451f5f1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1861562 @@ -0,0 +1,113 @@ + +piix crashes on mips when using multiple cpus + +Crash occurred while testing commit 330edfcc84a7: + +$ qemu-system-mips64el -cpu I6400 -append "clocksource=GIC console=ttyS0" -smp 8 -kernel vmlinux +Linux version 4.7.0-rc1 (phil@x1) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Sat Feb 1 13:15:19 UTC 2020 +earlycon: uart8250 at I/O port 0x3f8 (options '38400n8') +bootconsole [uart8250] enabled +CPU0 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +MIPS: machine is mti,malta +Software DMA cache coherency enabled +Determined physical RAM map: + memory: 0000000008000000 @ 0000000000000000 (usable) +Zone ranges: + DMA [mem 0x0000000000000000-0x0000000000ffffff] + DMA32 [mem 0x0000000001000000-0x00000000ffffffff] + Normal empty +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000000000-0x0000000007ffffff] +Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] +VP topology {8} total 8 +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +percpu: Embedded 5 pages/cpu @980000000107c000 s29664 r8192 d44064 u81920 +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8163 +Kernel command line: clocksource=GIC console=ttyS0 +log_buf_len individual max cpu contribution: 4096 bytes +log_buf_len total cpu_extra contributions: 28672 bytes +log_buf_len min size: 32768 bytes +log_buf_len: 65536 bytes +early log buf free: 30432(92%) +PID hash table entries: 512 (order: -2, 4096 bytes) +Dentry cache hash table entries: 16384 (order: 3, 131072 bytes) +Inode-cache hash table entries: 8192 (order: 2, 65536 bytes) +Writing ErrCtl register=00000000 +Readback ErrCtl register=00000000 +MAAR configuration: + [0]: 0x0000000000010000-0x0000000007ffffff speculate + [1]: disabled + [2]: disabled + [3]: disabled + [4]: disabled + [5]: disabled + [6]: disabled + [7]: disabled +Memory: 121104K/131072K available (5253K kernel code, 380K rwdata, 1276K rodata, 304K init, 278K bss, 9968K reserved, 0K cma-reserved) +Hierarchical RCU implementation. + Build-time adjustment of leaf fanout to 64. +NR_IRQS:256 +CPU frequency 200.00 MHz +GIC frequency 100.00 MHz +clocksource: GIC: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112702515 ns +clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112355619 ns +sched_clock: 32 bits at 100MHz, resolution 9ns, wraps every 21474556923ns +... +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +CPU7 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +Synchronize counters for CPU 7: done. +Brought up 8 CPUs +devtmpfs: initialized +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +NET: Registered protocol family 16 +pm-cps: CPC does not support clock gating +vgaarb: loaded +SCSI subsystem initialized +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [mem 0x10000000-0x17ffffff] +pci_bus 0000:00: root bus resource [io 0x1000-0x1fffff] +pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] +pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] +pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size) +pci 0000:00:0a.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +Aborted (core dumped) + +(gdb) bt +#0 0x00007fe1e8d37e35 in raise () at /lib64/libc.so.6 +#1 0x00007fe1e8d22895 in abort () at /lib64/libc.so.6 +#2 0x000055d442b388ba in acpi_gpe_ioport_get_ptr (addr=addr@entry=49312, ar=ar@entry=0x55d4444212d0) at hw/acpi/core.c:670 +#3 0x000055d442b388ba in acpi_gpe_ioport_writeb (ar=ar@entry=0x55d4444212d0, addr=addr@entry=49312, val=val@entry=181) at hw/acpi/core.c:680 +#4 0x000055d442d3f363 in gpe_writeb (opaque=0x55d444420800, addr=49312, val=181, width=<optimized out>) at hw/acpi/piix4.c:553 +#5 0x000055d442b9534b in memory_region_write_accessor (mr=mr@entry=0x55d4444211e0, addr=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) + at memory.c:483 +#6 0x000055d442b9305e in access_with_adjusted_size (addr=addr@entry=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry= + 0x55d442b95220 <memory_region_write_accessor>, mr=0x55d4444211e0, attrs=...) at memory.c:544 +#7 0x000055d442b976b4 in memory_region_dispatch_write (mr=mr@entry=0x55d4444211e0, addr=addr@entry=49312, data=<optimized out>, data@entry=327163317, op=op@entry=MO_64, attrs=...) at memory.c:1475 +#8 0x000055d442ba44fd in io_writex + (env=env@entry=0x55d443ec8f60, mmu_idx=mmu_idx@entry=0, val=val@entry=327163317, addr=addr@entry=10376293541929074848, retaddr=140608199778784, op=MO_64, iotlbentry=<optimized out>, iotlbentry=<optimized out>) + at accel/tcg/cputlb.c:980 +#9 0x000055d442baa43c in store_helper (op=MO_64, retaddr=140608199778784, oi=<optimized out>, val=<optimized out>, addr=10376293541929074848, env=0x55d443ec8f60) at accel/tcg/cputlb.c:1788 +#10 0x000055d442baa43c in helper_le_stq_mmu (env=0x55d443ec8f60, addr=10376293541929074848, val=327163317, oi=<optimized out>, retaddr=140608199778784) at accel/tcg/cputlb.c:1920 +#11 0x00007fe1e5cce1e0 in code_gen_buffer () +#12 0x000055d442bbc6d3 in cpu_tb_exec (itb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:172 +#13 0x000055d442bbc6d3 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:618 +#14 0x000055d442bbc6d3 in cpu_exec (cpu=cpu@entry=0x55d443ec0550) at accel/tcg/cpu-exec.c:731 +#15 0x000055d442b88580 in tcg_cpu_exec (cpu=0x55d443ec0550) at cpus.c:1405 +#16 0x000055d442b8a6f4 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x55d443ec0550) at cpus.c:1713 +#17 0x000055d442faeb7b in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:519 +#18 0x00007fe1e8ece4c0 in start_thread () at /lib64/libpthread.so.0 +#19 0x00007fe1e8dfc163 in clone () at /lib64/libc.so.6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863023 b/results/classifier/gemma3:12b/device/1863023 new file mode 100644 index 000000000..8866ee955 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1863247 b/results/classifier/gemma3:12b/device/1863247 new file mode 100644 index 000000000..7bb480bfd --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863247 @@ -0,0 +1,9 @@ + +AArch64 EXT instruction for V register does not clear MSB side bits + +On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. + +Example +ext v0.16b, v1.16b v2.16b, 8 + +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863333 b/results/classifier/gemma3:12b/device/1863333 new file mode 100644 index 000000000..86a346db7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863333 @@ -0,0 +1,73 @@ + +Assigning NVMe disk to a domain causes VFIO_MAP_DMA errors + +I'm seeing some errors when assigning my NVMe disk to qemu. This is the full command line: + + +/home/zippy/work/qemu/qemu.git/x86_64-softmmu/qemu-system-x86_64 \ +-name guest=fedora,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-fedora/master-key.aes \ +-machine pc-i440fx-4.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m size=4194304k,slots=16,maxmem=1099511627776k \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=2,threads=2 \ +-object iothread,id=iothread1 \ +-object iothread,id=iothread2 \ +-object iothread,id=iothread3 \ +-object iothread,id=iothread4 \ +-mem-prealloc \ +-mem-path /hugepages2M/libvirt/qemu/2-fedora \ +-numa node,nodeid=0,cpus=0,mem=4096 \ +-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=31,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-global PIIX4_PM.disable_s3=0 \ +-global PIIX4_PM.disable_s4=0 \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/fedora.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-2-storage","backing":null}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1 \ +-blockdev '{"driver":"nvme","device":"0000:02:00.0","namespace":1,"node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}' \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=libvirt-1-format,id=virtio-disk0 \ +-netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 \ +-device virtio-net-pci,host_mtu=9000,netdev=hostnet0,id=net0,mac=52:54:00:a4:6f:91,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,fd=35,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on \ +-device virtio-vga,id=video0,virgl=on,max_outputs=1,bus=pci.0,addr=0x2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on + +And these are the errors I see: + +2020-02-14T09:06:18.183167Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument +2020-02-14T09:10:49.753767Z qemu-system-x86_64: VFIO_MAP_DMA failed: Cannot allocate memory +2020-02-14T09:11:04.530344Z qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device +2020-02-14T09:11:04.531087Z qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device +2020-02-14T09:11:04.531230Z qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device + + +I'm doing nothing with the disk inside the guest, but: + + # dd if=/dev/vda of=/dev/null status=progress + +(the disk appears as /dev/vda in the guest). Surprisingly, I do not see these errors when I use the traditional PCI assignment (-device vfio-pci). My versions of kernel and qemu: + +moe ~ # uname -r +5.4.15-gentoo +moe ~ # /home/zippy/work/qemu/qemu.git/x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 4.2.50 (v4.2.0-1439-g5d6542bea7-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863441 b/results/classifier/gemma3:12b/device/1863441 new file mode 100644 index 000000000..ef2727482 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863441 @@ -0,0 +1,9 @@ + +cmd_mode_sense always reports 0x70, no CDROM present + +cmd_mode_sense + https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/atapi.c;hb=refs/heads/master#l852 +always reports 0x70 in byte 2 returned, indicating no CD-ROM present. + +If CD-ROM is present, should report 0x01 (or 0x11). +If CD-ROM absent, should report 0x70. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863526 b/results/classifier/gemma3:12b/device/1863526 new file mode 100644 index 000000000..71ac1b3c2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863526 @@ -0,0 +1,22 @@ + +NVIC CCR register not 8-bit accessible using Cortex-M4 + +Head at commit b29c3e23f64938. + +Running with '-d unimp,guest_errors -trace nvic\*' I get: + +8871@1581892794.295746:nvic_sysreg_read NVIC sysreg read addr 0xd88 data 0xf00000 size 4 +8871@1581892794.295752:nvic_sysreg_write NVIC sysreg write addr 0xd88 data 0xf00000 size 4 +8871@1581892794.297780:nvic_sysreg_write NVIC sysreg write addr 0xd08 data 0x4200 size 4 +8871@1581892794.298040:nvic_sysreg_write NVIC sysreg write addr 0xd15 data 0x0 size 1 +NVIC: Bad write of size 1 at offset 0xd15 +8871@1581892794.298081:nvic_sysreg_write NVIC sysreg write addr 0xd16 data 0x0 size 1 +NVIC: Bad write of size 1 at offset 0xd16 +8871@1581892794.298116:nvic_sysreg_write NVIC sysreg write addr 0xd17 data 0x0 size 1 +NVIC: Bad write of size 1 at offset 0xd17 +8871@1581892794.298156:nvic_sysreg_write NVIC sysreg write addr 0xd18 data 0x0 size 1 +8871@1581892794.298161:nvic_set_prio NVIC set irq 4 secure-bank 0 priority 0 +8871@1581892794.298164:nvic_recompute_state NVIC state recomputed: vectpending 0 vectpending_prio 256 exception_prio 256 +8871@1581892794.298168:nvic_irq_update NVIC vectpending 0 pending prio 256 exception_prio 256: setting irq line to 0 +8871@1581892794.298201:nvic_sysreg_write NVIC sysreg write addr 0xd19 data 0x0 size 1 +8871@1581892794.298206:nvic_set_prio NVIC set irq 5 secure-bank 0 priority 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863678 b/results/classifier/gemma3:12b/device/1863678 new file mode 100644 index 000000000..5b9e5d8f2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863678 @@ -0,0 +1,12 @@ + +qemu and virtio-vga black screen in Android + +QEMU emulator version 4.2.50 + +kernel 5.3.0-29-generic +host Ubuntu 19.10 +guest: Android 8.1 + +While trying to compile I get the following error + +qemu/slirp/src/misc.c:146: undefined reference to `g_spawn_async_with_fds' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863685 b/results/classifier/gemma3:12b/device/1863685 new file mode 100644 index 000000000..b399ca7db --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863685 @@ -0,0 +1,9 @@ + +ARM: HCR.TSW traps are not implemented + +On 32-bit and 64-bit ARM platforms, setting HCR.TSW is supposed to "Trap data or unified cache maintenance instructions that operate by Set/Way." Quoting the ARM manual: + +If EL1 is using AArch64 state, accesses to DC ISW, DC CSW, DC CISW are trapped to EL2, reported using EC syndrome value 0x18. +If EL1 is using AArch32 state, accesses to DCISW, DCCSW, DCCISW are trapped to EL2, reported using EC syndrome value 0x03. + +However, QEMU does not trap those instructions/registers. This was tested on the branch master of the git repo. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1863710 b/results/classifier/gemma3:12b/device/1863710 new file mode 100644 index 000000000..9f6cce5b5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1863710 @@ -0,0 +1,10 @@ + +qemu 4.2 does not process discard(trim) commands + +I'm using Arch Linux with qemu 4.2 and blktrace to monitor discard commands as they are sent to the hardware. Blktrace shows nothing as the VM is trimming the SSDs. + +I downgraded to qemu 4.1.1 and blktrace shows lots of discard commands as the VM is trimming. + +Kernel version is 5.5.4. + +Attached is the libvirt xml. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1864704 b/results/classifier/gemma3:12b/device/1864704 new file mode 100644 index 000000000..ea6aa57e4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1864704 @@ -0,0 +1,46 @@ + +No compatible -machine option in qemu-system-ppc64 for e6500 core + +Hi, + +I'm trying to use qemu-system-ppc64 for emulating a QorIQ T2080 (with e6500 cores). +However, I couldn't find any -machine option that matches -cpu e6500 option, which are listed below: + +C:\Program Files\qemu>qemu-system-ppc64 -machine help +Supported machines are: +40p IBM RS/6000 7020 (40p) +bamboo bamboo +g3beige Heathrow based PowerMAC +mac99 Mac99 based PowerMAC +mpc8544ds mpc8544ds +none empty machine +powernv8 IBM PowerNV (Non-Virtualized) POWER8 +powernv IBM PowerNV (Non-Virtualized) POWER9 (alias of powernv9) +powernv9 IBM PowerNV (Non-Virtualized) POWER9 +ppce500 generic paravirt e500 platform +prep PowerPC PREP platform (deprecated) +pseries-2.1 pSeries Logical Partition (PAPR compliant) +pseries-2.10 pSeries Logical Partition (PAPR compliant) +pseries-2.11 pSeries Logical Partition (PAPR compliant) +pseries-2.12 pSeries Logical Partition (PAPR compliant) +pseries-2.12-sxxm pSeries Logical Partition (PAPR compliant) +pseries-2.2 pSeries Logical Partition (PAPR compliant) +pseries-2.3 pSeries Logical Partition (PAPR compliant) +pseries-2.4 pSeries Logical Partition (PAPR compliant) +pseries-2.5 pSeries Logical Partition (PAPR compliant) +pseries-2.6 pSeries Logical Partition (PAPR compliant) +pseries-2.7 pSeries Logical Partition (PAPR compliant) +pseries-2.8 pSeries Logical Partition (PAPR compliant) +pseries-2.9 pSeries Logical Partition (PAPR compliant) +pseries-3.0 pSeries Logical Partition (PAPR compliant) +pseries-3.1 pSeries Logical Partition (PAPR compliant) +pseries-4.0 pSeries Logical Partition (PAPR compliant) +pseries-4.1 pSeries Logical Partition (PAPR compliant) +pseries pSeries Logical Partition (PAPR compliant) (alias of pseries-4.2) +pseries-4.2 pSeries Logical Partition (PAPR compliant) (default) +ref405ep ref405ep +sam460ex aCube Sam460ex +taihu taihu +virtex-ml507 Xilinx Virtex ML507 reference design + +I am wondering if anyone knows that is if any of them can be selected for such emulation? Thank you! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1864984 b/results/classifier/gemma3:12b/device/1864984 new file mode 100644 index 000000000..8d0b874af --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1866 b/results/classifier/gemma3:12b/device/1866 new file mode 100644 index 000000000..dbabc986b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1866 @@ -0,0 +1,2 @@ + +mips/mip64 virtio broken on master (and 8.1.0 with tcg fix) diff --git a/results/classifier/gemma3:12b/device/1867072 b/results/classifier/gemma3:12b/device/1867072 new file mode 100644 index 000000000..3c81a4556 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1867072 @@ -0,0 +1,10 @@ + +ARM: tag bits cleared in FAR_EL1 + +The ARM Architecture Reference Manual provides the following for FAR_EL1: + +"For a Data Abort or Watchpoint exception, if address tagging is enabled for the address accessed by the data access that caused the exception, then this field includes the tag." + +However, I have found that the tag bits in FAR_EL1 are always clear, even if the tag bits were set in the original access. + +I can reproduce the problem on both 4.1.1 and master (6e8a73e911f066527e775e04b98f31ebd19db600). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1867519 b/results/classifier/gemma3:12b/device/1867519 new file mode 100644 index 000000000..ba1b3fc41 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1867519 @@ -0,0 +1,48 @@ + +qemu 4.2 segfaults on VF detach + +After updating Ubuntu 20.04 to the Beta version, we get the following error and the virtual machines stucks when detaching PCI devices using virsh command: + +Error: +error: Failed to detach device from /tmp/vf_interface_attached.xml +error: internal error: End of file from qemu monitor + +steps to reproduce: + 1. create a VM over Ubuntu 20.04 (5.4.0-14-generic) + 2. attach PCI device to this VM (Mellanox VF for example) + 3. try to detaching the PCI device using virsh command: + a. create a pci interface xml file: + + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address type='pci' domain='0x0000' bus='0x11' slot='0x00' function='0x2' /> + </source> + </hostdev> + + b. #virsh detach-device <VM-Doman-name> <pci interface xml file> + + + +- Ubuntu release: + Description: Ubuntu Focal Fossa (development branch) + Release: 20.04 + +- Package ver: + libvirt0: + Installed: 6.0.0-0ubuntu3 + Candidate: 6.0.0-0ubuntu5 + Version table: + 6.0.0-0ubuntu5 500 + 500 http://il.archive.ubuntu.com/ubuntu focal/main amd64 Packages + *** 6.0.0-0ubuntu3 100 + 100 /var/lib/dpkg/status + +- What you expected to happen: + PCI device detached without any errors. + +- What happened instead: + getting the errors above and he VM stuck + +additional info: +after downgrading the libvirt0 package and all the dependent packages to 5.4 the previous, version, seems that the issue disappeared \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1869006 b/results/classifier/gemma3:12b/device/1869006 new file mode 100644 index 000000000..16af7178e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1869006 @@ -0,0 +1,26 @@ + +PCIe cards passthrough to TCG guest works on 2GB of guest memory but fails on 4GB (vfio_dma_map invalid arg) + +During one meeting coworker asked "did someone tried to passthrough PCIe card to other arch guest?" and I decided to check it. + +Plugged SATA and USB3 controllers into spare slots on mainboard and started playing. On 1GB VM instance it worked (both cold- and hot-plugged). On 4GB one it did not: + +Błąd podczas uruchamiania domeny: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup + self._backend.create() + File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1234, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22 +2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device vfio-pci,host=0000:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:29:00.0: failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument) + + +I played with memory and 3054 MB is maximum value possible to boot VM with coldplugged host PCIe cards. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1869426 b/results/classifier/gemma3:12b/device/1869426 new file mode 100644 index 000000000..7bf48dd78 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1869426 @@ -0,0 +1,35 @@ + +5.0rc0->4.2 serial migraiton + +Migrating from 5.0rc0->4.2 with pc-q35-4.2 we get an error: + +Unknown savevm section or instance 'serial' 1 + +dumping the migration streams it looks like 5.0 is duplicating the serial migration data: + + "serial (26)": { + "divider": "0x000c", + "rbr": "0x00", + "ier": "0x00", + "iir": "0x01", + "lcr": "0x00", + "mcr": "0x00", + "lsr": "0x60", + "msr": "0xb0", + "scr": "0x00", + "fcr_vmstate": "0x00" + }, + "serial (27)": { + "state": { + "divider": "0x000c", + "rbr": "0x00", + "ier": "0x00", + "iir": "0x01", + "lcr": "0x00", + "mcr": "0x00", + "lsr": "0x60", + "msr": "0xb0", + "scr": "0x00", + "fcr_vmstate": "0x00" + } + }, \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1870098 b/results/classifier/gemma3:12b/device/1870098 new file mode 100644 index 000000000..efe26bcc7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1871270 b/results/classifier/gemma3:12b/device/1871270 new file mode 100644 index 000000000..9e556c3d0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1873338 b/results/classifier/gemma3:12b/device/1873338 new file mode 100644 index 000000000..172403d3d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1873338 @@ -0,0 +1,6 @@ + +Dos on the fly CD image replacement is not Working with DOS + +Im not able to exchange CD image on the fly (needed for some games). I messed with command like - in console(ATL+CRTL+2) eject ide1-cd0 and change ide-cd0 D:/Games/!Emulators/Dos-QEMU/ISOs/TestChangeISO.iso , but system so never able to find new CD data.. simply drive so empty.. but when i reboot virtual machine, new change image is now working. + + Qemu 4.2. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1873340 b/results/classifier/gemma3:12b/device/1873340 new file mode 100644 index 000000000..1ed530ff9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1873340 @@ -0,0 +1,18 @@ + +KVM Old ATI(pre) AMD card passthrough is not working + +Hello, +tried to passthroug old ATI pre AMD PCI / PCI-E cards, on machine where anything else is working - Nvidia /Matrox / 3dfx cards.. + +Here are results: +ATI Mach 64 PCI - videocard - machine start segfault +ATI Rage XL PCI - videocard - machine start segfault +ATI Radeon 7000 PCI - Segmentation fault +ATI X600 Giabyte GV-RX60P128D - Segmentation fault +ATI X700 PCI-E Legend - videocard - completely broken picture from boot +ATI X800 XL PCI-E Gigabyte - videocard - completely broken picture from boot + All cards has last bioses. + +ATI X600 - HP one professional with DMS-59 connector, im unable to make passthrough, but im not able to set in Windows 98/WinXP machine.. anything less than 16 bit colors.. Im getting VM crashes or boot freezes, when i try to boot with more colors. + + Qemu 2.11 and 4.2, is the same, Mint Linux 19.3. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1874 b/results/classifier/gemma3:12b/device/1874 new file mode 100644 index 000000000..3379347f6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1874504 b/results/classifier/gemma3:12b/device/1874504 new file mode 100644 index 000000000..f320a6a37 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1874504 @@ -0,0 +1,26 @@ + +VFIO passthrough spits out thousands of messages + +started qemu as: +sudo qemu-system-sparc64 -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB + +messages received thousands of times: + +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu has granularity incompatible with target AS +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu map to non memory area 4079c000 + +qemu version (think telling a lie as sure its 5.0) +QEMU emulator version 4.2.92 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +pci device being passed through: + +0b:05.0 Display controller [0380]: 3DLabs Permedia II 2D+3D [3d3d:0009] (rev 01) + Subsystem: Tech-Source Permedia II 2D+3D [1227:0006] + Flags: medium devsel, IRQ 11 + Memory at 83000000 (32-bit, non-prefetchable) [disabled] [size=128K] + Memory at 82800000 (32-bit, non-prefetchable) [disabled] [size=8M] + Memory at 82000000 (32-bit, non-prefetchable) [disabled] [size=8M] + Expansion ROM at 83020000 [disabled] [size=64K] + Capabilities: <access denied> + Kernel driver in use: vfio-pci \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1875080 b/results/classifier/gemma3:12b/device/1875080 new file mode 100644 index 000000000..12550863a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1875080 @@ -0,0 +1,10 @@ + +USB host device data transfer with control endpoint + +QEMU emulator version 4.2.0 +Host -> Arch Linux kernel version: 5.4.34-1-lts +Guest -> Various Linux Distros + +I sent a control message with data through endpoint zero. +On the other side message is received with all fields correct except data buffer. +I've tested the data field inside guest with usbmon and data field was correct but after packet leaved qemu, data filed is lost. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1877 b/results/classifier/gemma3:12b/device/1877 new file mode 100644 index 000000000..85b13d7ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/1877 @@ -0,0 +1,244 @@ + +virtiofs Illegal Seek Error because of ivshmem device of looking-glass +Description of problem: +tl;dr: The dev "gnif" from looking-glass does not want to analyse this problem which his config from the documentation is causing. He insists someone opens a issue here at qemu's, so thats what i did now :) He also insists this problem is not caused by his config (even though the config is needed for looking-glass) and does not want to help or analyse this whole mess. Sorry if i'm a bit salty. + +Please see the following issues on his and the virtio-win github : \ +https://github.com/gnif/LookingGlass/issues/1089 + +https://github.com/gnif/LookingGlass/issues/1083 + +[https://github.com/virtio-win/kvm-guest-drivers-windows/issues/911](https://github.com/virtio-win/kvm-guest-drivers-windows/issues/911%5C) + +# +Steps to reproduce: +1. Create a VM +2. enable looking-glass (i used the latest Beta6 release from github) with the mentioned kernel module (i use manjaro and can use looking-glass-module-dkms from AUR) +3. add virtiofs from virt-manager +Additional information: +libvirt XML + +```plaintext +<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm"> + <name>win10</name> + <uuid>a026f749-3adc-4ab8-a5cf-521a4e8ec9d6</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://microsoft.com/win/10"/> + </libosinfo:libosinfo> + </metadata> + <memory unit="KiB">12582912</memory> + <currentMemory unit="KiB">12582912</currentMemory> + <memoryBacking> + <source type="memfd"/> + <access mode="shared"/> + </memoryBacking> + <vcpu placement="static">10</vcpu> + <os> + <type arch="x86_64" machine="pc-q35-5.1">hvm</type> + <loader readonly="yes" type="pflash">/usr/share/edk2-ovmf/x64/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <hyperv mode="custom"> + <relaxed state="on"/> + <vapic state="on"/> + <spinlocks state="on" retries="8191"/> + <vendor_id state="on" value="ASRock"/> + </hyperv> + <vmport state="off"/> + </features> + <cpu mode="host-passthrough" check="none" migratable="on"> + <topology sockets="1" dies="1" cores="5" threads="2"/> + </cpu> + <clock offset="localtime"> + <timer name="hpet" present="yes"/> + <timer name="hypervclock" present="yes"/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled="no"/> + <suspend-to-disk enabled="yes"/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type="file" device="cdrom"> + <driver name="qemu" type="raw"/> + <target dev="sdc" bus="sata"/> + <readonly/> + <boot order="1"/> + <address type="drive" controller="0" bus="0" target="0" unit="2"/> + </disk> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2" cache="none" discard="unmap"/> + <source file="/opt/windowsos.qcow2"/> + <target dev="sdd" bus="scsi"/> + <boot order="2"/> + <address type="drive" controller="0" bus="0" target="0" unit="3"/> + </disk> + <disk type="block" device="disk"> + <driver name="qemu" type="raw" cache="none" io="native" discard="unmap"/> + <source dev="/dev/zvol/satassd2tb/vms/windowsdata2"/> + <target dev="sde" bus="scsi"/> + <address type="drive" controller="0" bus="0" target="0" unit="4"/> + </disk> + <controller type="usb" index="0" model="qemu-xhci" ports="15"> + <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/> + </controller> + <controller type="pci" index="0" model="pcie-root"/> + <controller type="pci" index="1" model="pcie-root-port"> + <model name="pcie-root-port"/> + <target chassis="1" port="0x10"/> + <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"/> + <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"/> + <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"/> + <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"/> + <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"/> + <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"/> + <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"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/> + </controller> + <controller type="pci" index="9" model="pcie-to-pci-bridge"> + <model name="pcie-pci-bridge"/> + <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/> + </controller> + <controller type="pci" index="10" model="pcie-root-port"> + <model name="pcie-root-port"/> + <target chassis="10" port="0x18"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/> + </controller> + <controller type="pci" index="11" model="pcie-root-port"> + <model name="pcie-root-port"/> + <target chassis="11" port="0x19"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/> + </controller> + <controller type="pci" index="12" model="pcie-root-port"> + <model name="pcie-root-port"/> + <target chassis="12" port="0x1a"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/> + </controller> + <controller type="scsi" index="0" model="virtio-scsi"> + <address type="pci" domain="0x0000" bus="0x08" slot="0x00" function="0x0"/> + </controller> + <controller type="sata" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/> + </controller> + <controller type="virtio-serial" index="0"> + <address type="pci" domain="0x0000" bus="0x0c" slot="0x00" function="0x0"/> + </controller> + <filesystem type="mount" accessmode="passthrough"> + <driver type="virtiofs"/> + <source dir="/home/nemu/Downloads"/> + <target dir="nemu_downloads"/> + <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> + </filesystem> + <interface type="bridge"> + <mac address="52:54:00:cc:75:be"/> + <source bridge="vmbr0"/> + <model type="virtio"/> + <link state="up"/> + <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/> + </interface> + <interface type="bridge"> + <mac address="52:54:00:b8:8d:30"/> + <source bridge="vmbr1"/> + <model type="virtio"/> + <address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/> + </interface> + <channel type="spicevmc"> + <target type="virtio" name="com.redhat.spice.0"/> + <address type="virtio-serial" controller="0" bus="0" port="1"/> + </channel> + <input type="mouse" bus="virtio"> + <address type="pci" domain="0x0000" bus="0x0a" slot="0x00" function="0x0"/> + </input> + <input type="keyboard" bus="virtio"> + <address type="pci" domain="0x0000" bus="0x0b" slot="0x00" function="0x0"/> + </input> + <input type="mouse" bus="ps2"/> + <input type="keyboard" bus="ps2"/> + <graphics type="spice" port="-1" autoport="no" listen="127.0.0.1"> + <listen type="address" address="127.0.0.1"/> + <image compression="off"/> + <gl enable="no"/> + </graphics> + <sound model="ich9"> + <audio id="1"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/> + </sound> + <audio id="1" type="spice"/> + <video> + <model type="vga" vram="16384" heads="1" primary="yes"> + <acceleration accel3d="no"/> + </model> + <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/> + </video> + <hostdev mode="subsystem" type="pci" managed="yes"> + <source> + <address domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> + </source> + <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/> + </hostdev> + <hostdev mode="subsystem" type="pci" managed="yes"> + <source> + <address domain="0x0000" bus="0x04" slot="0x00" function="0x1"/> + </source> + <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/> + </hostdev> + <redirdev bus="usb" type="spicevmc"> + <address type="usb" bus="0" port="2"/> + </redirdev> + <redirdev bus="usb" type="spicevmc"> + <address type="usb" bus="0" port="3"/> + </redirdev> + <redirdev bus="usb" type="spicevmc"> + <address type="usb" bus="0" port="4"/> + </redirdev> + <redirdev bus="usb" type="spicevmc"> + <address type="usb" bus="0" port="5"/> + </redirdev> + <watchdog model="itco" action="reset"/> + <memballoon model="none"/> + </devices> + <qemu:commandline> + <qemu:arg value="-device"/> + <qemu:arg value="{"driver":"ivshmem-plain","id":"shmem1","memdev":"looking-glass"}"/> + <qemu:arg value="-object"/> + <qemu:arg value="{"qom-type":"memory-backend-file","id":"looking-glass","mem-path":"/dev/kvmfr0","size":134217728,"share":true}"/> + </qemu:commandline> +</domain> +``` + +If more logs are needed please just ask. I will gladly provide them. diff --git a/results/classifier/gemma3:12b/device/1878057 b/results/classifier/gemma3:12b/device/1878057 new file mode 100644 index 000000000..689c38b11 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878057 @@ -0,0 +1,49 @@ + +null-ptr dereference in megasas_command_complete + +Hello, +While fuzzing, I found an input that triggers a null-pointer dereference in +megasas_command_complete: + +==14959==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000003 (pc 0x55b1d11b4df1 bp 0x7ffeb55ca450 sp 0x7ffeb55ca1e0 T0) +==14959==The signal is caused by a WRITE memory access. +==14959==Hint: address points to the zero page. + #0 0x55b1d11b4df1 in megasas_command_complete /home/alxndr/Development/qemu/hw/scsi/megasas.c:1877:40 + #1 0x55b1d11759ec in scsi_req_complete /home/alxndr/Development/qemu/hw/scsi/scsi-bus.c:1430:5 + #2 0x55b1d115c98f in scsi_aio_complete /home/alxndr/Development/qemu/hw/scsi/scsi-disk.c:216:5 + #3 0x55b1d151c638 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1375:9 + #4 0x55b1d151c638 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1385:5 + #5 0x55b1d16f3a5b in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #6 0x55b1d16f3a5b in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #7 0x55b1d16fe43e in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #8 0x55b1d16f54fa in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #9 0x7f47937c89ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #10 0x55b1d16fbef4 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #11 0x55b1d16fbef4 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #12 0x55b1d16fbef4 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #13 0x55b1d0cd16a6 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #14 0x55b1d1608dca in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #15 0x7f4792378e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #16 0x55b1d091d7b9 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x8f47b9) + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -no-shutdown -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001814 +outl 0xcfc 0xc021 +outl 0xcf8 0x80001818 +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x80001810 +outl 0xcfc 0xe10c0000 +outl 0xcf8 0x8000f810 +write 0x44b20 0x1 0x35 +write 0x44b00 0x1 0x03 +write 0xc021e10c0040 0x81 0x014b04000131000000014b04000138000000014b0400013f000000014b04000146000000014b0400014d000000014b04000154000000014b0400015b000000014b04000162000000014b04000169000000014b04000170000000014b04000177000000014b0400017e000000014b04000185000000014b0400018c000000014b04 +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -no-shutdown -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 -nographic < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878134 b/results/classifier/gemma3:12b/device/1878134 new file mode 100644 index 000000000..488013f6b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878134 @@ -0,0 +1,46 @@ + +Assertion failures in ati_reg_read_offs/ati_reg_write_offs + +Hello, +While fuzzing, I found inputs that trigger assertion failures in +ati_reg_read_offs/ati_reg_write_offs + +uint32_t extract32(uint32_t, int, int): Assertion `start >= 0 && length > 0 && length <= 32 - start' failed + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555556e760c0 <str> "start >= 0 && length > 0 && length <= 32 - start", file=0x555556e76120 <str> "/home/alxndr/Development/qemu/include/qemu/bitops.h", line=0x12c, function=0x555556e76180 <__PRETTY_FUNCTION__.extract32> "uint32_t extract32(uint32_t, int, int)") at assert.c:101 +#4 0x000055555653d8a7 in ati_mm_read (opaque=<optimized out>, addr=0x1a, size=<optimized out>) at /home/alxndr/Development/qemu/include/qemu/log-for-trace.h:29 +#5 0x000055555653c825 in ati_mm_read (opaque=<optimized out>, addr=0x4, size=<optimized out>) at /home/alxndr/Development/qemu/hw/display/ati.c:289 +#6 0x000055555601446e in memory_region_read_accessor (mr=0x63100004dc20, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:434 +#7 0x0000555556001a70 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x63100004dc20, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#8 0x0000555556001a70 in memory_region_dispatch_read1 (mr=0x63100004dc20, addr=0x4, pval=<optimized out>, size=0x4, attrs=...) at /home/alxndr/Development/qemu/memory.c:1396 + + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000004 0x1 0x1a +readq 0xe2000000 +EOF + +Similarly for ati_reg_write_offs: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000000 0x8 0x6a00000000006a00 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878136 b/results/classifier/gemma3:12b/device/1878136 new file mode 100644 index 000000000..59ce188cf --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878136 @@ -0,0 +1,45 @@ + + Assertion failures in ati_reg_read_offs/ati_reg_write_offs + +Hello, +While fuzzing, I found inputs that trigger assertion failures in +ati_reg_read_offs/ati_reg_write_offs + +uint32_t extract32(uint32_t, int, int): Assertion `start >= 0 && length > 0 && length <= 32 - start' failed + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555556e760c0 <str> "start >= 0 && length > 0 && length <= 32 - start", file=0x555556e76120 <str> "/home/alxndr/Development/qemu/include/qemu/bitops.h", line=0x12c, function=0x555556e76180 <__PRETTY_FUNCTION__.extract32> "uint32_t extract32(uint32_t, int, int)") at assert.c:101 +#4 0x000055555653d8a7 in ati_mm_read (opaque=<optimized out>, addr=0x1a, size=<optimized out>) at /home/alxndr/Development/qemu/include/qemu/log-for-trace.h:29 +#5 0x000055555653c825 in ati_mm_read (opaque=<optimized out>, addr=0x4, size=<optimized out>) at /home/alxndr/Development/qemu/hw/display/ati.c:289 +#6 0x000055555601446e in memory_region_read_accessor (mr=0x63100004dc20, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:434 +#7 0x0000555556001a70 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x63100004dc20, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#8 0x0000555556001a70 in memory_region_dispatch_read1 (mr=0x63100004dc20, addr=0x4, pval=<optimized out>, size=0x4, attrs=...) at /home/alxndr/Development/qemu/memory.c:1396 + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000004 0x1 0x1a +readq 0xe2000000 +EOF + +Similarly for ati_reg_write_offs: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000000 0x8 0x6a00000000006a00 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878253 b/results/classifier/gemma3:12b/device/1878253 new file mode 100644 index 000000000..f118e5c5c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878253 @@ -0,0 +1,57 @@ + +null-ptr dereference in address_space_to_flatview through ide + +Hello, +While fuzzing, I found an input that triggers a null-ptr dereference in +address_space_to_flatview through ide: + +==31699==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x55e0f562bafd bp 0x7ffee92355b0 sp 0x7ffee92354e0 T0) +==31699==The signal is caused by a READ memory access. +==31699==Hint: address points to the zero page. + #0 0x55e0f562bafd in address_space_to_flatview /home/alxndr/Development/qemu/include/exec/memory.h:693:12 + #1 0x55e0f562bafd in address_space_write /home/alxndr/Development/qemu/exec.c:3267:14 + #2 0x55e0f562dd9c in address_space_unmap /home/alxndr/Development/qemu/exec.c:3592:9 + #3 0x55e0f5ab8277 in dma_memory_unmap /home/alxndr/Development/qemu/include/sysemu/dma.h:145:5 + #4 0x55e0f5ab8277 in dma_blk_unmap /home/alxndr/Development/qemu/dma-helpers.c:104:9 + #5 0x55e0f5ab8277 in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:139:5 + #6 0x55e0f617a6b8 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1398:9 + #7 0x55e0f617a6b8 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1408:5 + #8 0x55e0f6355efb in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #9 0x55e0f6355efb in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #10 0x55e0f63608ce in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #11 0x55e0f635799a in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #12 0x7f16e85d69ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #13 0x55e0f635e384 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #14 0x55e0f635e384 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #15 0x55e0f635e384 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #16 0x55e0f593d676 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #17 0x55e0f6267c6a in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #18 0x7f16e7186e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #19 0x55e0f55727b9 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x9027b9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/include/exec/memory.h:693:12 in address_space_to_flatview + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc -nographic -drive file=null-co://,if=ide,cache=writeback,format=raw -nodefaults -display none -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80000920 +outl 0xcfc 0xc001 +outl 0xcf8 0x80000924 +outl 0xcf8 0x80000904 +outw 0xcfc 0x7 +outb 0x1f7 0xc8 +outw 0x3f6 0xe784 +outw 0x3f6 0xeb01 +outb 0xc005 0x21 +write 0x2103 0x1 0x4e +outb 0xc000 0x1b +outw 0x1f7 0xff35 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc -nographic -drive file=null-co://,if=ide,cache=writeback,format=raw -nodefaults -display none -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878255 b/results/classifier/gemma3:12b/device/1878255 new file mode 100644 index 000000000..c3ba43c52 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878255 @@ -0,0 +1,39 @@ + +Assertion failure in bdrv_aio_cancel, through ide + +Hello, +While fuzzing, I found an input that triggers an assertion failure in bdrv_aio_cancel, through ide: + +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x0000555556a8d396 in bdrv_aio_cancel (acb=0x607000061290) at /home/alxndr/Development/qemu/block/io.c:2746 +#3 0x0000555556a58525 in blk_aio_cancel (acb=0x2) at /home/alxndr/Development/qemu/block/block-backend.c:1540 +#4 0x0000555556552f5b in ide_reset (s=<optimized out>) at /home/alxndr/Development/qemu/hw/ide/core.c:1318 +#5 0x0000555556552aeb in ide_bus_reset (bus=0x62d000017398) at /home/alxndr/Development/qemu/hw/ide/core.c:2422 +#6 0x0000555556579ba5 in ahci_reset_port (s=<optimized out>, port=<optimized out>) at /home/alxndr/Development/qemu/hw/ide/ahci.c:650 +#7 0x000055555657bd8d in ahci_port_write (s=0x61e000014d70, port=0x2, offset=<optimized out>, val=0x10) at /home/alxndr/Development/qemu/hw/ide/ahci.c:360 +#8 0x000055555657bd8d in ahci_mem_write (opaque=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/ide/ahci.c:513 +#9 0x00005555560028d7 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#10 0x0000555556002280 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x61e000014da0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#11 0x0000555556002280 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x10, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#12 0x0000555555f171d4 in flatview_write_continue (fv=<optimized out>, addr=0xe106c22c, attrs=..., ptr=<optimized out>, len=0x1, addr1=0x7fffffffb8d0, l=<optimized out>, mr=0x61e000014da0) at /home/alxndr/Development/qemu/exec.c:3137 +#13 0x0000555555f0fb98 in flatview_write (fv=0x60600003b180, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe106c000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0x0 0x3 0x2780e7 +write 0xe106c22c 0xd 0x1130c218021130c218021130c2 +write 0xe106c218 0x15 0x110010110010110010110010110010110010110010 +EOF + +I also attached the commands to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878259 b/results/classifier/gemma3:12b/device/1878259 new file mode 100644 index 000000000..ad76d8d4b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878259 @@ -0,0 +1,55 @@ + +Null-pointer dereference in megasas_handle_frame + +Hello, +While fuzzing, I found an input that triggers a null-pointer dereference in megasas_handle_frame: + +==1595==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55e3e83e6e08 bp 0x7ffdb04c63b0 sp 0x7ffd +==1595==The signal is caused by a READ memory access. +==1595==Hint: address points to the zero page. + #0 0x55e3e83e6e08 in megasas_handle_frame /home/alxndr/Development/qemu/hw/scsi/megasas.c:1952:36 + #1 0x55e3e83e6e08 in megasas_mmio_write /home/alxndr/Development/qemu/hw/scsi/megasas.c:2122:9 + #2 0x55e3e7d088d6 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 + #3 0x55e3e7d0827f in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 + #4 0x55e3e7d0827f in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + #5 0x55e3e7c1d1d3 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 + #6 0x55e3e7c15b97 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 + #7 0x55e3e7c15b97 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 + #8 0x55e3e7d03bc4 in qtest_process_command /home/alxndr/Development/qemu/qtest.c:567:9 + #9 0x55e3e7cfe74d in qtest_process_inbuf /home/alxndr/Development/qemu/qtest.c:710:9 + #10 0x55e3e8804cad in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9 + #11 0x7f602ef2a897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #12 0x55e3e8948384 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #13 0x55e3e8948384 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #14 0x55e3e8948384 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #15 0x55e3e7f27676 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #16 0x55e3e8851c6a in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #17 0x7f602dadae0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #18 0x55e3e7b5c7b9 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x9027b9) + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -qtest stdio -nographic -monitor none -serial none -M q35 -device megasas +outl 0xcf8 0x80001814 +outl 0xcfc 0xc021 +outl 0xcf8 0x80001818 +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x80001810 +outl 0xcfc 0xe10c0000 +outl 0xcf8 0x8000f810 +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe10c4000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0xe10c4384 0x15 0x838383838383838383838383838383838383838383 +write 0xc021e10c00c0 0x4 0x082c04dd +EOF + +I also attached the commands to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -qtest stdio -nographic -monitor none -serial none -M q35 -device megasas < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878263 b/results/classifier/gemma3:12b/device/1878263 new file mode 100644 index 000000000..ea7c1e789 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1878263 @@ -0,0 +1,45 @@ + +Assertion-failure in scsi_dma_complete, with megasas + +Hello, +While fuzzing, I found an input that triggers an assertion-failure in scsi_dma_complete, with megasas: + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555556efa460 <str> "r->req.aiocb != NULL", file=0x555556ef9b20 <str> "/home/alxndr/Development/qemu/hw/scsi/scsi-disk.c", line=0x124, function=0x555556efa560 <__PRETTY_FUNCTION__.scsi_dma_complete> "void scsi_dma_complete(void *, int)") at assert.c:101 +#4 0x000055555669d473 in scsi_dma_complete (opaque=0x616000040280, ret=<optimized out>) at /home/alxndr/Development/qemu/hw/scsi/scsi-disk.c:292 +#5 0x000055555639c89b in dma_complete (dbs=<optimized out>, ret=<optimized out>) at /home/alxndr/Development/qemu/dma-helpers.c:118 +#6 0x000055555639c89b in dma_blk_cb (opaque=<optimized out>, ret=<optimized out>) at /home/alxndr/Development/qemu/dma-helpers.c:136 +#7 0x000055555639bd58 in dma_blk_io (ctx=<optimized out>, sg=<optimized out>, offset=<optimized out>, align=<optimized out>, io_func=<optimized +out>, io_func_opaque=<optimized out>, cb=<optimized out>, opaque=<optimized out>, dir=<optimized out>) at /home/alxndr/Development/qemu/dma-helpers.c:232 +#8 0x000055555669baa5 in scsi_write_data (req=0x616000040280) at /home/alxndr/Development/qemu/hw/scsi/scsi-disk.c:583 +#9 0x00005555566b5d93 in scsi_req_continue (req=0x616000040280) at /home/alxndr/Development/qemu/hw/scsi/scsi-bus.c:1337 +#10 0x00005555566f52e3 in megasas_enqueue_req (cmd=<optimized out>, is_write=<optimized out>) at /home/alxndr/Development/qemu/hw/scsi/megasas.c:1651 +#11 0x00005555566e276f in megasas_handle_io (s=<optimized out>, cmd=<optimized out>, frame_cmd=<optimized out>) at /home/alxndr/Development/qemu/hw/scsi/megasas.c:1790 +#12 0x00005555566e276f in megasas_handle_frame (s=<optimized out>, frame_addr=<optimized out>, frame_count=<optimized out>) at /home/alxndr/Development/qemu/hw/scsi/megasas.c:1969 +#13 0x00005555566e276f in megasas_mmio_write (opaque=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/scsi/megasas.c:2122 +#14 0x00005555560028d7 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#15 0x0000555556002280 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x7fffeeb301e0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#16 0x0000555556002280 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x17, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#17 0x0000555555f171d4 in flatview_write_continue (fv=<optimized out>, addr=0xc1c0, attrs=..., ptr=<optimized out>, len=0x1, addr1=0x7fffffffae00, l=<optimized out>, mr=0x7fffeeb301e0) at /home/alxndr/Development/qemu/exec.c:3137 +#18 0x0000555555f0fb98 in flatview_write (fv=0x606000038180, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 + + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -qtest stdio -nographic -monitor none -serial none -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 +outl 0xcf8 0x80001818 +outl 0xcfc 0xc101 +outl 0xcf8 0x8000181c +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x8000186a +write 0x14 0x1 0xfe +write 0x0 0x1 0x02 +outb 0xc1c0 0x17 +EOF + +I also attached the commands to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -qtest stdio -nographic -monitor none -serial none -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1878915 b/results/classifier/gemma3:12b/device/1878915 new file mode 100644 index 000000000..fbc9596e8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1879175 b/results/classifier/gemma3:12b/device/1879175 new file mode 100644 index 000000000..56b3b5caa --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1880 b/results/classifier/gemma3:12b/device/1880 new file mode 100644 index 000000000..32ffa9113 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1880 @@ -0,0 +1,14 @@ + +CXL Mem enable error +Description of problem: +During the process of booting, the following info indicate that the CXL Mem is not enabled. +``` +Media not active (-16) +probe of mem0 failed with error -16 +``` +Steps to reproduce: +1. Compile Linux kernel v5.18 as shown in the QEMU doc +2. Run the above-mentioned script +3. Check the booting script +Additional information: +Could you give me some hints of how to operate on the CXL device properly? Thanks a lot. diff --git a/results/classifier/gemma3:12b/device/1880189 b/results/classifier/gemma3:12b/device/1880189 new file mode 100644 index 000000000..b06ba777c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1880189 @@ -0,0 +1,108 @@ + +I/O writes make cirrus_invalidate_region() crash + +As of commit d19f1ab0, LLVM libFuzzer found: + +qemu-fuzz-i386: hw/display/cirrus_vga.c:646: void cirrus_invalidate_region(CirrusVGAState *, int, int, int, int): Assertion `off_cur_end >= off_cur' failed. +==1336555== ERROR: libFuzzer: deadly signal + #0 0xaaaaaf943ce4 in __sanitizer_print_stack_trace + #1 0xaaaaaf899474 in fuzzer::PrintStackTrace() + #2 0xaaaaaf884c80 in fuzzer::Fuzzer::CrashCallback() + #3 0xffff9b4e8568 (linux-vdso.so.1+0x568) + #4 0xffff99ac406c in __libc_signal_restore_set /build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #5 0xffff99ac406c in raise /build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #6 0xffff99ab0d64 in abort /build/glibc-w4ZToO/glibc-2.31/stdlib/abort.c:79:7 + #7 0xffff99abd5d8 in __assert_fail_base /build/glibc-w4ZToO/glibc-2.31/assert/assert.c:92:3 + #8 0xffff99abd640 in __assert_fail /build/glibc-w4ZToO/glibc-2.31/assert/assert.c:101:3 + #9 0xaaaab040768c in cirrus_invalidate_region + #10 0xaaaab0405404 in cirrus_bitblt_solidfill + #11 0xaaaab0402a88 in cirrus_bitblt_start + #12 0xaaaab04046a8 in cirrus_write_bitblt + #13 0xaaaab0400db4 in cirrus_vga_write_gr + #14 0xaaaab03fd33c in cirrus_vga_ioport_write + #15 0xaaaaafb41674 in memory_region_write_accessor + #16 0xaaaaafb411ec in access_with_adjusted_size + #17 0xaaaaafb40180 in memory_region_dispatch_write + #18 0xaaaaaf995dfc in flatview_write_continue + #19 0xaaaaaf985bd8 in flatview_write + #20 0xaaaaaf98574c in address_space_write + #21 0xaaaab110510c in ioport_fuzz_qtest + #22 0xaaaab1103a48 in i440fx_fuzz_qtest + #23 0xaaaab11010d8 in LLVMFuzzerTestOneInput + +Reproducer: + +qemu-system-i386 -M isapc,accel=qtest -vga cirrus -qtest stdio << 'EOF' +outl 0x03b1 0x2fdc1001 +outb 0x03cc 0xe +outb 0x03cc 0xe +outb 0x03cc 0x2f +outb 0x03cc 0xe +outb 0x03cc 0x2f +outb 0x03cc 0xe +outl 0x03cc 0xedc100e +outb 0x03cc 0x2f +outl 0x03cc 0xe24f40e +outl 0x03cc 0x2f23dc12 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe2af40e +outl 0x03cc 0x2f235612 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0x2fdcf40e +outb 0x03cc 0xe +outl 0x03cc 0xedc100e +outb 0x03cc 0x2f +outl 0x03cc 0xe24f40e +outl 0x03cc 0xe23dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xedc100e +outl 0x03cc 0x2fdc400e +outb 0x03cc 0xe +outl 0x03cc 0xe130100e +outb 0x03cc 0x2f +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe33f40e +outl 0x03cc 0xdc235612 +outb 0x03cc 0xe +outl 0x03cc 0x2fdc400e +outb 0x03cc 0xe +outl 0x03cc 0xfb24100e +outb 0x03cc 0x2f +outl 0x03cc 0xdc10dc0e +outl 0x03cc 0x2f31dc12 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0x1021f40e +EOF +qemu-system-i386: hw/display/cirrus_vga.c:645: cirrus_invalidate_region: Assertion `off_cur_end >= off_cur' failed. +Aborted (core dumped) + +(gdb) bt +#0 0x00007f1d019fee35 in raise () at /lib64/libc.so.6 +#1 0x00007f1d019e9895 in abort () at /lib64/libc.so.6 +#2 0x00007f1d019e9769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f1d019f7566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x00005645cb447a37 in cirrus_invalidate_region (s=0x5645cd237540, off_begin=2097204, off_pitch=251, bytesperline=1, lines=7169) at hw/display/cirrus_vga.c:645 +#5 0x00005645cb447cc8 in cirrus_bitblt_solidfill (s=0x5645cd237540, blt_rop=0) at hw/display/cirrus_vga.c:704 +#6 0x00005645cb448886 in cirrus_bitblt_start (s=0x5645cd237540) at hw/display/cirrus_vga.c:1005 +#7 0x00005645cb448dd1 in cirrus_write_bitblt (s=0x5645cd237540, reg_value=47) at hw/display/cirrus_vga.c:1090 +#8 0x00005645cb449b02 in cirrus_vga_write_gr (s=0x5645cd237540, reg_index=49, reg_value=47) at hw/display/cirrus_vga.c:1593 +#9 0x00005645cb44bb2f in cirrus_vga_ioport_write (opaque=0x5645cd237540, addr=975, val=47, size=1) at hw/display/cirrus_vga.c:2686 +#10 0x00005645cb1e0d6e in memory_region_write_accessor (mr=0x5645cd247f10, addr=31, value=0x7fff178d6c18, size=1, shift=24, mask=255, attrs=...) at memory.c:483 +#11 0x00005645cb1e0f7f in access_with_adjusted_size (addr=28, value=0x7fff178d6c18, size=4, access_size_min=1, access_size_max=1, access_fn= + 0x5645cb1e0c8b <memory_region_write_accessor>, mr=0x5645cd247f10, attrs=...) at memory.c:544 +#12 0x00005645cb1e3e9d in memory_region_dispatch_write (mr=0x5645cd247f10, addr=28, data=791796754, op=MO_32, attrs=...) at memory.c:1476 +#13 0x00005645cb1845e5 in flatview_write_continue (fv=0x5645cd65e510, addr=972, attrs=..., ptr=0x7fff178d6da4, len=4, addr1=28, l=4, mr=0x5645cd247f10) at exec.c:3137 +#14 0x00005645cb18472a in flatview_write (fv=0x5645cd65e510, addr=972, attrs=..., buf=0x7fff178d6da4, len=4) at exec.c:3177 +#15 0x00005645cb184a7d in address_space_write (as=0x5645cbd7bb20 <address_space_io>, addr=972, attrs=..., buf=0x7fff178d6da4, len=4) at exec.c:3268 +#16 0x00005645cb1db385 in cpu_outl (addr=972, val=791796754) at ioport.c:80 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1880539 b/results/classifier/gemma3:12b/device/1880539 new file mode 100644 index 000000000..25e19774e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1880539 @@ -0,0 +1,26 @@ + +I/O write make QXL abort in qxl_set_mode() + +libFuzzer found: + +qxl-0: guest bug: qxl_add_memslot: guest_start > guest_end 0xffffffffffffffff > 0x3ffffff +qemu-fuzz-i386: hw/display/qxl.c:1611: void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0' failed. +==8134== ERROR: libFuzzer: deadly signal + #0 0x55fddfcfb3f0 in __sanitizer_print_stack_trace (qemu-fuzz-i386+0xcb13f0) + #1 0x55fddfc0a3e1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0xbc03e1) + #2 0x55fddfbeac6f in fuzzer::Fuzzer::CrashCallback() (qemu-fuzz-i386+0xba0c6f) + #3 0x55fddfbeacc3 in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0xba0cc3) + #4 0x7fd640644c6f (/lib64/libpthread.so.0+0x12c6f) + #5 0x7fd640483e34 in __GI_raise (/lib64/libc.so.6+0x37e34) + #6 0x7fd64046e894 in __GI_abort (/lib64/libc.so.6+0x22894) + #7 0x7fd64046e768 in __assert_fail_base.cold (/lib64/libc.so.6+0x22768) + #8 0x7fd64047c565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x55fde08afd8b in qxl_set_mode (qemu-fuzz-i386+0x1865d8b) + #10 0x55fde08b9602 in ioport_write (qemu-fuzz-i386+0x186f602) + #11 0x55fddff170a7 in memory_region_write_accessor (qemu-fuzz-i386+0xecd0a7) + #12 0x55fddff16c13 in access_with_adjusted_size (qemu-fuzz-i386+0xeccc13) + #13 0x55fddff157b4 in memory_region_dispatch_write (qemu-fuzz-i386+0xecb7b4) + +Can be reproduce doing "writeb 0x06 0x23" on QXL I/O (PCI BAR #3). + +Command line: 'qemu-system-i386 -display none -M pc -vga qxl' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1880822 b/results/classifier/gemma3:12b/device/1880822 new file mode 100644 index 000000000..85063613f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1880822 @@ -0,0 +1,4 @@ + +CVE-2020-13253 QEMU: sd: OOB access could crash the guest resulting in DoS + +An out-of-bounds read access issue was found in the SD Memory Card emulator of the QEMU. It occurs while performing block write commands via sdhci_write(), if a guest user has sent 'address' which is OOB of 's->wp_groups'. A guest user/process may use this flaw to crash the QEMU process resulting in DoS. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1881552 b/results/classifier/gemma3:12b/device/1881552 new file mode 100644 index 000000000..6c9478b9a --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1882065 b/results/classifier/gemma3:12b/device/1882065 new file mode 100644 index 000000000..1ae2a5a7d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1882065 @@ -0,0 +1,28 @@ + +Could this cause OOB bug ? + +In function megasas_handle_scsi(hw/scsi/megasas.c): + +```c +static int megasas_handle_scsi(MegasasState *s, MegasasCmd *cmd, + int frame_cmd) +{ + ............................................................................ + cdb = cmd->frame->pass.cdb; + target_id = cmd->frame->header.target_id; + lun_id = cmd->frame->header.lun_id; + cdb_len = cmd->frame->header.cdb_len; + ............................................................................ + if (cdb_len > 16) { + trace_megasas_scsi_invalid_cdb_len( + mfi_frame_desc[frame_cmd], is_logical, + target_id, lun_id, cdb_len); + megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE)); + cmd->frame->header.scsi_status = CHECK_CONDITION; + s->event_count++; + return MFI_STAT_SCSI_DONE_WITH_ERROR; + } +} +``` + +Two variables, frame_cmd and cdb_len, can be controlled by guest os. So can mfi_frame_desc[frame_cmd] cause OOB bug ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1882350 b/results/classifier/gemma3:12b/device/1882350 new file mode 100644 index 000000000..55a52cb51 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1882350 @@ -0,0 +1,37 @@ + +it always create sdx device when I configure ide device with hdx name + +I have configured 2 ide disks with name starting with hd, but when the vm boots up, it shows disks whose name starting with sd. + +1. ide disks in vm xml: + + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/data3_raw.qcow2'/> + <target dev='hdc' bus='ide'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/data2.qcow2'/> + <target dev='hdb' bus='ide'/> + </disk> + + +2. in VM: + +sda 8:0 0 2G 0 disk +sdb 8:16 0 1G 0 disk + + +3. from vm.log: + +le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev t + + +4. rpm info: (I got the same issue on 2 diff envs) +(1) env1 +qemu-kvm-1.5.3-105 +libvirt-3.2.0-14.el7 +(2) env2 +libvirt-5.9.0-1.el8 +qemu-4.1.0-1.el8 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1882784 b/results/classifier/gemma3:12b/device/1882784 new file mode 100644 index 000000000..544e24276 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1882784 @@ -0,0 +1,32 @@ + +Legacy IGD passthrough in QEMU 5 disabled + +Bug with tag v5.0.0, or commit fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6 + +As of QEMU 5 Legacy IGD PT is no longer working. + +Host is a Xeon E3-1226 v3 and my method to test is to run the following: + +./qemu-system-x86_64 \ + -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1f' \ + -device 'vfio-pci,host=00:02.0,addr=02.0' \ + -L '/usr/share/kvm' \ + -nographic \ + -vga none \ + -nodefaults + +in the hope of seeing a "IGD device 0000:00:02.0 cannot support legacy mode due to existing devices at address 1f.0" error. + +The culprit appears to be this commit: + +https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19 + +Specifically the following block in pci-quirks.c: + +#ifdef CONFIG_VFIO_IGD + vfio_probe_igd_bar4_quirk(vdev, nr); +#endif + +as the kconfig variable CONFIG_VFIO_IGD doesn't appear to be available outside of makefiles as described here: https://qemu.weilnetz.de/doc/devel/kconfig.html. I can confirm that the igd code is being pulled in as removing this check, as would defining the variable I presume, makes Legacy IGD PT work again (ie I see the expected "existing devices" error). + +I first spotted this in Proxmox, but have confirmed the bug by building QEMU sources. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1882787 b/results/classifier/gemma3:12b/device/1882787 new file mode 100644 index 000000000..7310ae0eb --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1883728 b/results/classifier/gemma3:12b/device/1883728 new file mode 100644 index 000000000..f15ec548e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1883728 @@ -0,0 +1,16 @@ + +address_space_unmap: Assertion `mr != NULL' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1883729 b/results/classifier/gemma3:12b/device/1883729 new file mode 100644 index 000000000..3677507f3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1883729 @@ -0,0 +1,16 @@ + +xhci_find_stream: Assertion `streamid != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1883732 b/results/classifier/gemma3:12b/device/1883732 new file mode 100644 index 000000000..1cdb445a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1883732 @@ -0,0 +1,16 @@ + +xhci_kick_epctx: Assertion `ring->dequeue != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1883733 b/results/classifier/gemma3:12b/device/1883733 new file mode 100644 index 000000000..6962952a1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1883733 @@ -0,0 +1,16 @@ + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1884693 b/results/classifier/gemma3:12b/device/1884693 new file mode 100644 index 000000000..92b47a53f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1884693 @@ -0,0 +1,56 @@ + +Assertion failure in address_space_unmap through ahci_map_clb_address + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe1068000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0xe1068304 0x1 0x21 +write 0xe1068318 0x1 0x21 +write 0xe1068384 0x1 0x21 +write 0xe1068398 0x2 0x21 +EOF + +Stack trace: +#0 0x55bfabfe9ea0 in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +#1 0x55bfabfc8ef9 in __sanitizer_print_stack_trace (build/i386-softmmu/qemu-fuzz-i386+0x7b7ef9) +#2 0x55bfabfaf933 in fuzzer::PrintStackTrace() FuzzerUtil.cpp:210:5 +#3 0x7f88df76110f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1410f) +#4 0x7f88df5a4760 in __libc_signal_restore_set /build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10 +#5 0x7f88df5a4760 in raise /build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7f88df58e55a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7 +#7 0x7f88df58e42e in __assert_fail_base /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:92:3 +#8 0x7f88df59d091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +#9 0x55bfabff7182 in address_space_unmap exec.c:3602:9 +#10 0x55bfac4a452f in dma_memory_unmap include/sysemu/dma.h:148:5 +#11 0x55bfac4a452f in map_page hw/ide/ahci.c:254:9 +#12 0x55bfac4a1f98 in ahci_map_clb_address hw/ide/ahci.c:748:5 +#13 0x55bfac4a1f98 in ahci_cond_start_engines hw/ide/ahci.c:276:14 +#14 0x55bfac4a074e in ahci_port_write hw/ide/ahci.c:339:9 +#15 0x55bfac4a074e in ahci_mem_write hw/ide/ahci.c:513:9 +#16 0x55bfac0e0dc2 in memory_region_write_accessor memory.c:483:5 +#17 0x55bfac0e0bde in access_with_adjusted_size memory.c:544:18 +#18 0x55bfac0e0917 in memory_region_dispatch_write memory.c +#19 0x55bfabffa4fd in flatview_write_continue exec.c:3146:23 +#20 0x55bfabff569b in flatview_write exec.c:3186:14 +#21 0x55bfabff569b in address_space_write exec.c:3280:18 +#22 0x55bfac8982a9 in op_write_pattern tests/qtest/fuzz/general_fuzz.c:407:5 +#23 0x55bfac897749 in general_fuzz tests/qtest/fuzz/general_fuzz.c:481:17 +#24 0x55bfac8930a2 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:136:5 +#25 0x55bfabfb0e68 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:558:15 +#26 0x55bfabfb0485 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) FuzzerLoop.cpp:470:3 +#27 0x55bfabfb18a1 in fuzzer::Fuzzer::MutateAndTestOne() FuzzerLoop.cpp:701:19 +#28 0x55bfabfb2305 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:837:5 +#29 0x55bfabfa2018 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:846:6 +#30 0x55bfabfb8722 in main FuzzerMain.cpp:19:10 +#31 0x7f88df58fe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +#32 0x55bfabf97869 in _start (build/i386-softmmu/qemu-fuzz-i386+0x786869) + +The same error can be triggered through ahci_map_fis_address @ hw/ide/ahci.c:721:5 +Found with generic device fuzzer: https://<email address hidden>/ + +Please let me know if I can provide any further info. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1884831 b/results/classifier/gemma3:12b/device/1884831 new file mode 100644 index 000000000..fa87312da --- /dev/null +++ b/results/classifier/gemma3:12b/device/1884831 @@ -0,0 +1,22 @@ + +qemu-nbd fails to discard bigger chunks + +This report is moved from systemd to here: +https://github.com/systemd/systemd/issues/16242 + +A qemu-nbd device reports that it can discard a lot of bytes: + +cat /sys/block/nbd0/queue/discard_max_bytes +2199023255040 + +And indeed, discard works with small images: + +$ qemu-img create -f qcow2 /tmp/image.img 2M +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 + +but not for bigger ones (still smaller than discard_max_bytes): + +$ qemu-img create -f qcow2 /tmp/image.img 5G +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1885350 b/results/classifier/gemma3:12b/device/1885350 new file mode 100644 index 000000000..324817489 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1885350 @@ -0,0 +1,24 @@ + +RISCV dynamic rounding mode is not behaving correctly + +Hello, + +I’ve gone through the RISC-V code in latest QEMU release (qemu-5.0.0-rc2) and when checking the Floating point encodings I found the rounding mode is only updated if the opcode field “rm” is changed “ctx->frm == rm”. But according to RISC-V Volume I: Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding mode is set with frm value. + +So for the same rm value (=7) and when changing frm value seeking different rounding modes, and according to the below code, the rounding mode won’t be updated. Please correct me if I got this implementation wrong. + +static void gen_set_rm(DisasContext *ctx, int rm) +{ + TCGv_i32 t0; + if (ctx->frm == rm) { + return; + } + ctx->frm = rm; + t0 = tcg_const_i32(rm); + gen_helper_set_rounding_mode(cpu_env, t0); + tcg_temp_free_i32(t0); +} + + +My testcase: +I set statically the rm field in the instruction to 7 and before this execution I changed the value of frm field in fcsr register. For the 1st time it worked (according to the code above, the rm is updated so the round mode will also be updated). But when changing fcsr register an re-execute the instruction, there's no difference and the rounding mode is the same like the previous frm value. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1887303 b/results/classifier/gemma3:12b/device/1887303 new file mode 100644 index 000000000..163dc3275 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1887303 @@ -0,0 +1,207 @@ + +Assertion failure in *bmdma_active_if `bmdma->bus->retry_unit != (uint8_t)-1' failed. + +Hello, +Here is a QTest Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x176 0x3538 +outw 0x376 0x6007 +outw 0x376 0x6b6b +outw 0x176 0x985c +outl 0xcf8 0x80000903 +outl 0xcfc 0x2f2931 +outl 0xcf8 0x80000920 +outb 0xcfc 0x6b +outb 0x68 0x7 +outw 0x176 0x2530 +EOF + +Here is the call-stack: + + #8 0x7f00e0443091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 0x55e163f5a1af in bmdma_active_if /home/alxndr/Development/qemu/include/hw/ide/pci.h:59:5 + #10 0x55e163f5a1af in bmdma_prepare_buf /home/alxndr/Development/qemu/hw/ide/pci.c:132:19 + #11 0x55e163f4f00d in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:898:17 + #12 0x55e163de86ad in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 + #13 0x55e163de86ad in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 + #14 0x55e1642ade85 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #15 0x55e1642ade85 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #16 0x55e16443556f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #17 0x55e16443556f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #18 0x55e16440fac3 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #19 0x55e164436dac in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #20 0x7f00e16e29ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #21 0x55e164442f2b in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #22 0x55e164442f2b in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #23 0x55e164442f2b in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #24 0x55e164376953 in flush_events /home/alxndr/Development/qemu/tests/qtest/fuzz/fuzz.c:47:9 + #25 0x55e16437b8fa in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:544:17 + +================================= + +Here is the same assertion failure but triggered through a different call-stack: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x171 0x2fe9 +outb 0x177 0xa0 +outl 0x170 0x928 +outl 0x170 0x2b923b31 +outl 0x170 0x800a24d7 +outl 0xcf8 0x80000903 +outl 0xcfc 0x842700 +outl 0xcf8 0x80000920 +outb 0xcfc 0x5e +outb 0x58 0x7 +outb 0x376 0x5 +outw 0x376 0x11 +outw 0x176 0x3538 +EOF + +Call-stack: + #8 0x7f00e0443091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 0x55e163f5a622 in bmdma_active_if /home/alxndr/Development/qemu/include/hw/ide/pci.h:59:5 + #10 0x55e163f5a622 in bmdma_rw_buf /home/alxndr/Development/qemu/hw/ide/pci.c:187:19 + #11 0x55e163f57577 in ide_atapi_cmd_read_dma_cb /home/alxndr/Development/qemu/hw/ide/atapi.c:375:13 + #12 0x55e163f44c55 in ide_buffered_readv_cb /home/alxndr/Development/qemu/hw/ide/core.c:650:9 + #13 0x55e1642ade85 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #14 0x55e1642ade85 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #15 0x55e16443556f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #16 0x55e16443556f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #17 0x55e16440fac3 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #18 0x55e164436dac in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #19 0x7f00e16e29ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #20 0x55e164442f2b in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #21 0x55e164442f2b in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #22 0x55e164442f2b in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #23 0x55e164376953 in flush_events /home/alxndr/Development/qemu/tests/qtest/fuzz/fuzz.c:47:9 + #24 0x55e16437b8fa in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:544:17 + +================================= + +The first reproducer with -trace ide*: +[I 1594579788.601818] OPENED +26995@1594579788.617583:ide_reset IDEstate 0x565534a7b898 +26995@1594579788.617684:ide_reset IDEstate 0x565534a7bc68 +26995@1594579788.618019:ide_reset IDEstate 0x565534a7c188 +26995@1594579788.618087:ide_reset IDEstate 0x565534a7c558 +26995@1594579788.619271:ide_reset IDEstate 0x565534a7c188 +26995@1594579788.619377:ide_reset IDEstate 0x565534a7c558 +26995@1594579788.623224:ide_reset IDEstate 0x565534a7b898 +26995@1594579788.623267:ide_reset IDEstate 0x565534a7bc68 +26995@1594579788.623273:ide_reset IDEstate 0x565534a7c188 +26995@1594579788.623275:ide_reset IDEstate 0x565534a7c558 +[R +0.023386] outw 0x176 0x3538 +26995@1594579788.625224:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x565534a7c100 IDEState 0x565534a7c188 +26995@1594579788.625228:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625230:ide_exec_cmd IDE exec cmd: bus 0x565534a7c100; state 0x565534a7c558; cmd 0x35 +[S +0.023416] OK +[R +0.023442] outw 0x376 0x6007 +26995@1594579788.625263:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x07; bus 0x565534a7c100 +[S +0.023447] OK +[R +0.023455] outw 0x376 0x6b6b +26995@1594579788.625276:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x6b; bus 0x565534a7c100 +[S +0.023460] OK +[R +0.023464] outw 0x176 0x985c +26995@1594579788.625285:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x5c; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625287:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x98; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625289:ide_exec_cmd IDE exec cmd: bus 0x565534a7c100; state 0x565534a7c558; cmd 0x98 +[S +0.023473] OK +[R +0.023477] outl 0xcf8 0x80000903 +[S +0.023481] OK +[R +0.023485] outl 0xcfc 0x2f2931 +[S +0.023492] OK +[R +0.023496] outl 0xcf8 0x80000920 +[S +0.023498] OK +[R +0.023503] outb 0xcfc 0x6b +[S +0.023644] OK +[R +0.023651] outb 0x68 0x7 +26995@1594579788.625548:ide_dma_cb IDEState 0x565534a7c558; sector_num=1 n=255 cmd=DMA WRITE +[S +0.023809] OK +[R +0.023817] outw 0x176 0x2530 +26995@1594579788.625638:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x30; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625640:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x25; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625642:ide_exec_cmd IDE exec cmd: bus 0x565534a7c100; state 0x565534a7c558; cmd 0x25 +[S +0.023827] OK +qemu-system-i386: /home/alxndr/Development/qemu/include/hw/ide/pci.h:59: IDEState *bmdma_active_if(BMDMAState *): Assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. + +================================= + +The second reproducer with -trace ide*: + +[I 1594579681.691528] OPENED +8293@1594579681.707423:ide_reset IDEstate 0x55fc044c3898 +8293@1594579681.707540:ide_reset IDEstate 0x55fc044c3c68 +8293@1594579681.707902:ide_reset IDEstate 0x55fc044c4188 +8293@1594579681.707969:ide_reset IDEstate 0x55fc044c4558 +8293@1594579681.709859:ide_reset IDEstate 0x55fc044c4188 +8293@1594579681.709976:ide_reset IDEstate 0x55fc044c4558 +8293@1594579681.714051:ide_reset IDEstate 0x55fc044c3898 +8293@1594579681.714073:ide_reset IDEstate 0x55fc044c3c68 +8293@1594579681.714076:ide_reset IDEstate 0x55fc044c4188 +8293@1594579681.714079:ide_reset IDEstate 0x55fc044c4558 +[R +0.024386] outw 0x171 0x2fe9 +8293@1594579681.715950:ide_ioport_write IDE PIO wr @ 0x171 (Features); val 0xe9; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +8293@1594579681.715955:ide_ioport_write IDE PIO wr @ 0x172 (Sector Count); val 0x2f; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +OK +[S +0.024430] OK +[R +0.024436] outb 0x177 0xa0 +8293@1594579681.715967:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa0; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +8293@1594579681.715970:ide_exec_cmd IDE exec cmd: bus 0x55fc044c4100; state 0x55fc044c4188; cmd 0xa0 +OK +[S +0.024444] OK +[R +0.024448] outl 0x170 0x928 +8293@1594579681.715978:ide_data_writel IDE PIO wr @ 0x170 (Data: Long); val 0x00000928; bus 0x55fc044c4100; IDEState 0x55fc044c4188 +OK +[S +0.024453] OK +[R +0.024456] outl 0x170 0x2b923b31 +8293@1594579681.715986:ide_data_writel IDE PIO wr @ 0x170 (Data: Long); val 0x2b923b31; bus 0x55fc044c4100; IDEState 0x55fc044c4188 +OK +[S +0.024460] OK +[R +0.024464] outl 0x170 0x800a24d7 +8293@1594579681.715994:ide_data_writel IDE PIO wr @ 0x170 (Data: Long); val 0x800a24d7; bus 0x55fc044c4100; IDEState 0x55fc044c4188 +8293@1594579681.715996:ide_atapi_cmd IDEState: 0x55fc044c4188; cmd: 0x28 +8293@1594579681.716000:ide_atapi_cmd_packet IDEState: 0x55fc044c4188; limit=0xeb14 packet: 28 09 00 00 31 3b 92 2b d7 24 0a 80 +8293@1594579681.716004:ide_atapi_cmd_read IDEState: 0x55fc044c4188; read dma: LBA=12603 nb_sectors=11223 +OK +[S +0.024479] OK +[R +0.024483] outl 0xcf8 0x80000903 +OK +[S +0.024485] OK +[R +0.024489] outl 0xcfc 0x842700 +OK +[S +0.024604] OK +[R +0.024610] outl 0xcf8 0x80000920 +OK +[S +0.024613] OK +[R +0.024616] outb 0xcfc 0x5e +OK +[S +0.024720] OK +[R +0.024726] outb 0x58 0x7 +8293@1594579681.716258:ide_atapi_cmd_read_dma_cb_aio IDEState: 0x55fc044c4188; aio read: lba=12603 n=64 +OK +[S +0.024786] OK +[R +0.024791] outb 0x376 0x5 +8293@1594579681.716322:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x05; bus 0x55fc044c4100 +OK +[S +0.024797] OK +[R +0.024800] outw 0x376 0x11 +8293@1594579681.716330:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x11; bus 0x55fc044c4100 +OK +[S +0.024804] OK +[R +0.024807] outw 0x176 0x3538 +8293@1594579681.716337:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +8293@1594579681.716340:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x55fc044c4100 IDEState 0x55fc044c4558 +8293@1594579681.716342:ide_exec_cmd IDE exec cmd: bus 0x55fc044c4100; state 0x55fc044c4558; cmd 0x35 +8293@1594579681.716388:ide_dma_cb IDEState 0x55fc044c4558; sector_num=504 n=257 cmd=DMA WRITE +OK +[S +0.024882] OK +qemu-system-i386: /home/alxndr/Development/qemu/include/hw/ide/pci.h:59: IDEState *bmdma_active_if(BMDMAState *): Assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1887309 b/results/classifier/gemma3:12b/device/1887309 new file mode 100644 index 000000000..3b73d2dba --- /dev/null +++ b/results/classifier/gemma3:12b/device/1887309 @@ -0,0 +1,85 @@ + +Floating-point exception in ide_set_sector + +Hello, +Here is a reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x176 0x3538 +outl 0xcf8 0x80000903 +outl 0xcfc 0x184275c +outb 0x376 0x2f +outb 0x376 0x0 +outw 0x176 0xa1a4 +outl 0xcf8 0x80000920 +outb 0xcfc 0xff +outb 0xf8 0x9 +EOF + +The stack-trace: +==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) + #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 + #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 + #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 + #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 + #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) + +With -trace ide* + +12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +[R +0.024963] outw 0x176 0x3538 +12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +OK +[S +0.025002] OK +[R +0.025012] outl 0xcf8 0x80000903 +OK +[S +0.025018] OK +[R +0.025026] outl 0xcfc 0x184275c +OK +[S +0.025210] OK +[R +0.025219] outb 0x376 0x2f +12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +OK +[S +0.025229] OK +[R +0.025234] outb 0x376 0x0 +12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +OK +[S +0.025240] OK +[R +0.025246] outw 0x176 0xa1a4 +12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +OK +[S +0.025265] OK +[R +0.025270] outl 0xcf8 0x80000920 +OK +[S +0.025274] OK +[R +0.025279] outb 0xcfc 0xff +OK +[S +0.025443] OK +[R +0.025451] outb 0xf8 0x9 +12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +OK +[S +0.025724] OK +UndefinedBehaviorSanitizer:DEADLYSIGNAL +==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1888 b/results/classifier/gemma3:12b/device/1888 new file mode 100644 index 000000000..358b731b8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1888 @@ -0,0 +1,13 @@ + +megasas: Buffer I/O error on dev sda / critical target error, dev sda, sector 0 op 0x0:(READ) +Description of problem: +Since QEMU 7.2.0 when using `megasas` device the guest kernel is unable to I/O with the device (Input/output error) also producing errors messages in `dmesg` like these: +``` +[ 18.739344] critical target error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 +[ 18.739925] Buffer I/O error on dev sda, logical block 0, async page read +[ 18.740374] Dev sda: unable to read RDB block 0 +``` + +Relevant options are: `-device megasas -blockdev driver=null-co,read-zeroes=on,node-name=null -device scsi-hd,drive=null` then in guest `modprobe megaraid-sas`. With qcow2 images - errors are the same. + +I also tested that the same commands produce no errors on QEMU 6.0.0 - 7.1.0. diff --git a/results/classifier/gemma3:12b/device/1888417 b/results/classifier/gemma3:12b/device/1888417 new file mode 100644 index 000000000..ccfcea242 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1888417 @@ -0,0 +1,6 @@ + +Latest QEMU git build on Arch linux causes PCI Passthrough host to hang on guest reboot. + +Current Arch linux release, up-to-date as of 7/21/2020. + +Running a windows 7 virtual machine (also happens with windows 10, possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is attempted to be restarted, either through the guest interface, or by libvirt's gui interface "Virtual Machine Manager", it hangs in a "paused" state once the VM shutsdown, and just before the reboot can take place. A force-stop of the VM allows the VM to be properly booted without any disk error checks, alluding to a clean shutdown, but failed reboot. The VM can be properly shutdown using the guests shutdown function, or the libvirt manager shutdown, without any hangs. Reverting to Arch stable build QEMU 5.0.0-7 fixes the issue. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1888918 b/results/classifier/gemma3:12b/device/1888918 new file mode 100644 index 000000000..c1ed5dbe9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1888918 @@ -0,0 +1,74 @@ + +qemu-system-ppc: Floating point instructions do not properly generate the SPE/Embedded Floating-Point Unavailable interrupt + +When emulating certain floating point instructions or vector instructions on PowerPC machines, QEMU does not properly generate the SPE/Embedded Floating-Point Unavailable interrupt. + +As described in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0, available at https://www.nxp.com/docs/en/reference-manual/SPEPEM.pdf: + +> An SPE/embedded floating-point unavailable exception occurs on an attempt to execute any of the +> following instructions and MSR[SPV] is not set: +> * SPE instruction (except brinc) +> * An embedded scalar double-precision instruction +> * A vector single-precision floating-point instructions +> It is not used by embedded scalar single-precision floating-point instructions + +This behavior was partially reported in Bug #1611394, however the issue is larger than what is described in that bug. As mentioned in that bug, some single-precision instructions generate the exception (while they should not), which is incorrect but does not typically produce an incorrect output. What is more of an issue is that several double-precision and vector instructions do not generate the exception (while they should), and this break support for lazy FPU/vector context switching in Linux (for example). + +The upper 32-bit of the double-precision/vector registers (which are in fact hidden in the general purpose registers) is not properly saved/restored, and this causes arithmetic errors. This was observed very frequently on a commercial project that does a lot of double-precision computations. The application works perfectly fine on an MPC8548 CPU, but fails often with QEMU. + +The issue can be reproduced using the attached Linux program "spe-bug.c". This program properly prints the number 42 (as the result of some very simple double-precision computation) on real PowerPC hardware, but prints an incorrect result (typically 0) on QEMU. + +This issue was first discovered in an older version of QEMU, but is also reproduced in the latest: + +# git rev-parse HEAD +7adfbea8fd1efce36019a0c2f198ca73be9d3f18 +# ppc-softmmu/qemu-system-ppc --version +QEMU emulator version 5.0.91 (v5.1.0-rc1-28-g7adfbea8fd-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +Upon further analysis a total of 39 instructions are misbehaving: + +efsabs: raised: 1, expected: 0 +efsnabs: raised: 1, expected: 0 +efsneg: raised: 1, expected: 0 +efdcfs: raised: 0, expected: 1 +efdcfsf: raised: 0, expected: 1 +efdcfsi: raised: 0, expected: 1 +efdcfuf: raised: 0, expected: 1 +efdcfui: raised: 0, expected: 1 +efdctsf: raised: 0, expected: 1 +efdctsi: raised: 0, expected: 1 +efdctsiz: raised: 0, expected: 1 +efdctuf: raised: 0, expected: 1 +efdctui: raised: 0, expected: 1 +efdctuiz: raised: 0, expected: 1 +efscfd: raised: 0, expected: 1 +evfscfsf: raised: 0, expected: 1 +evfscfsi: raised: 0, expected: 1 +evfscfuf: raised: 0, expected: 1 +evfscfui: raised: 0, expected: 1 +evfsctsf: raised: 0, expected: 1 +evfsctsi: raised: 0, expected: 1 +evfsctsiz: raised: 0, expected: 1 +evfsctuf: raised: 0, expected: 1 +evfsctui: raised: 0, expected: 1 +evfsctuiz: raised: 0, expected: 1 +brinc: raised: 0, expected: 1 +efsadd: raised: 1, expected: 0 +efsdiv: raised: 1, expected: 0 +efsmul: raised: 1, expected: 0 +efssub: raised: 1, expected: 0 +evsplatfi: raised: 0, expected: 1 +evsplati: raised: 0, expected: 1 +efscmpeq: raised: 1, expected: 0 +efscmpgt: raised: 1, expected: 0 +efscmplt: raised: 1, expected: 0 +efststeq: raised: 1, expected: 0 +efststgt: raised: 1, expected: 0 +efststlt: raised: 1, expected: 0 +evsel: raised: 0, expected: 1 + +When "raised" is 0 and "expected" is 1, this means that the SPE/Embedded Floating-Point Unavailable interrupt was not generated while it should have. +When "raised" is 1 and "expected" is 0, this means that the SPE/Embedded Floating-Point Unavailable interrupt was generated while it should not have (Bug #1611394). + +A comprehensive program testing all the instructions listed in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0 is posted in the comments of this ticket, and can be used to reproduce the issue, and validate the future fix. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1888964 b/results/classifier/gemma3:12b/device/1888964 new file mode 100644 index 000000000..9ce17f20d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1889621 b/results/classifier/gemma3:12b/device/1889621 new file mode 100644 index 000000000..685f6f855 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1889621 @@ -0,0 +1,98 @@ + +ARM Highbank Crashes Realted to GIC + +Hello, +Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. + +Reproducer 1: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writel 0xfff11f00 0x8405f559 +writel 0xfff117fd 0x5c057bd8 +EOF + +==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +==10595==The signal is caused by a READ memory access. + #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 + #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 + #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 + #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 + #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 + #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +================================================================= + +Reproducer 2: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writeq 0xfff11f00 0x613a650f0fda6555 +EOF + +==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +READ of size 8 at 0x608000001c80 thread T0 + #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 + #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 + #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 + #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 + #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +================================================================= + +Reproducer 3: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writeq 0xfff11000 0x700000b +writeq 0xfff11f00 0x4f4f4fff54a7afaf +writel 0xfff10100 0x600001ff +EOF + +==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +READ of size 1 at 0x62b000006a92 thread T0 + #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 + #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 + #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 + #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 + #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 + #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 + #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 + #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 + #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 + #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 + #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 + #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 + #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 + #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) + +0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +allocated by thread T0 here: + #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) + #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 + #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 + #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 + #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 + #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 + #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 + #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 + #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + + +Let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1889945 b/results/classifier/gemma3:12b/device/1889945 new file mode 100644 index 000000000..a64b73ab6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1889945 @@ -0,0 +1,117 @@ + +virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded + +Bug in QEMU 5.0.0: + +virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded. +If iommu_platform is disabled the guest immediately locks up as a result of the configured PCIe-Passthrough. + +Host system: +- Arch Linux amd64 +- AMD Ryzen Platform +- QEMU 5.0.0 + +Guest system: +- Windows Server 2019 (also happens in linux installations) +- PCIe GPU hostdev +- virtiofs passthrough + +Many thanks for any advice. + +QEMU LOG: +2020-07-28 19:20:07.197+0000: Starting external device: virtiofsd +/usr/lib/qemu/virtiofsd --fd=29 -o source=/viofstest +2020-07-28 19:20:07.207+0000: starting up libvirt version: 6.5.0, qemu version: 5.0.0, kernel: 5.7.10-arch1-1, hostname: mspc +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-7-win \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-7-win/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-7-win/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-7-win/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=win,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-win/master-key.aes \ +-blockdev '{"driver":"file","filename":"/usr/share/ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,kernel_irqchip=on,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=whatever,kvm=off \ +-m 2048 \ +-overcommit mem-lock=off \ +-smp 8,sockets=8,cores=1,threads=1 \ +-object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/7-win,share=yes,size=2147483648 \ +-numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \ +-uuid c8efa194-52f8-4526-a0f8-29a254839b55 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=29,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 ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot menu=off,strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-pci-bridge,id=pci.2,bus=pci.1,addr=0x0 \ +-device pcie-root-port,port=0x11,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x5 \ +-device pcie-root-port,port=0x16,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x6 \ +-device pcie-root-port,port=0x17,chassis=9,id=pci.9,bus=pcie.0,addr=0x2.0x7 \ +-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,multifunction=on,addr=0x3 \ +-device pcie-root-port,port=0x19,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x1 \ +-device pcie-root-port,port=0x1a,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x2 \ +-device pcie-root-port,port=0x8,chassis=13,id=pci.13,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x9,chassis=14,id=pci.14,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0xa,chassis=15,id=pci.15,bus=pcie.0,addr=0x1.0x2 \ +-device pcie-root-port,port=0xb,chassis=16,id=pci.16,bus=pcie.0,addr=0x1.0x3 \ +-device nec-usb-xhci,id=usb,bus=pci.7,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.14,addr=0x0 \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/ssd/windows","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \ +-device virtio-blk-pci,bus=pci.3,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/ssd/windows-ssdgames1","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":"raw","file":"libvirt-2-storage"}' \ +-device virtio-blk-pci,bus=pci.9,addr=0x0,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/hdd/win-games1","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,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \ +-device virtio-blk-pci,bus=pci.13,addr=0x0,drive=libvirt-1-format,id=virtio-disk2,write-cache=on \ +-chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-7-win/fs0-fs.sock \ +-device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=viofstest,iommu_platform=on,ats=on,bus=pci.15,addr=0x0 \ +-netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=34 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fb:0c:28,bus=pci.10,addr=0x0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-device virtio-keyboard-pci,id=input0,bus=pci.12,addr=0x0 \ +-device virtio-tablet-pci,id=input1,bus=pci.8,addr=0x0 \ +-device virtio-mouse-pci,id=input2,bus=pci.11,addr=0x0 \ +-device ich9-intel-hda,id=sound0,bus=pci.2,addr=0x1 \ +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-device vfio-pci,host=0000:08:00.0,id=hostdev0,bus=pci.5,addr=0x0,rombar=1 \ +-device vfio-pci,host=0000:08:00.1,id=hostdev1,bus=pci.6,addr=0x0,rombar=1 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \ +-object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:0a:00.3-usb-0:3:1.0-event-kbd,grab_all=on,repeat=on \ +-object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:0a:00.3-usb-0:4:1.0-event-mouse \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: high-privileges +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: custom-argv +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: host-cpu +<--- VIOFS DRIVER GETS LOADED HERE ---> +2020-07-28T19:20:57.568089Z qemu-system-x86_64: Failed to read msg header. Read -1 instead of 12. Original request 1566376224. +2020-07-28T19:20:57.568120Z qemu-system-x86_64: Fail to update device iotlb +2020-07-28T19:20:57.568147Z qemu-system-x86_64: Failed to read msg header. Read 0 instead of 12. Original request 1566376528. +2020-07-28T19:20:57.568151Z qemu-system-x86_64: Fail to update device iotlb +2020-07-28T19:20:57.568153Z qemu-system-x86_64: Failed to set msg fds. +2020-07-28T19:20:57.568156Z qemu-system-x86_64: vhost_set_vring_call failed: Invalid argument (22) +2020-07-28T19:20:57.568160Z qemu-system-x86_64: Failed to set msg fds. +2020-07-28T19:20:57.568162Z qemu-system-x86_64: vhost_set_vring_call failed: Invalid argument (22) +2020-07-28T19:20:57.568296Z qemu-system-x86_64: Failed to read from slave. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890155 b/results/classifier/gemma3:12b/device/1890155 new file mode 100644 index 000000000..2f2d8c571 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890155 @@ -0,0 +1,39 @@ + +Abort in vmxnet3_validate_interrupt_idx + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x52 0x1 0x61 +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + +============================================================== + #7 0x55b271a89b67 in hw_error /home/alxndr/Development/qemu/general-fuzz/softmmu/cpus.c:927:5 + #8 0x55b272fc6433 in vmxnet3_validate_interrupt_idx /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1355:9 + #9 0x55b272fc4e6d in vmxnet3_validate_interrupts /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1364:5 + #10 0x55b272fbe723 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1546:5 + #11 0x55b272fb6fba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #12 0x55b272fb410f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #13 0x55b271ac4193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #14 0x55b271ac3637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #15 0x55b271ac1256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #16 0x55b270e724a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #17 0x55b270e5acc6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + + +qemu: hardware error: Bad interrupt index: 97 +Aborted + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890310 b/results/classifier/gemma3:12b/device/1890310 new file mode 100644 index 000000000..2c14a70eb --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890310 @@ -0,0 +1,48 @@ + +Segfault in artist.c:block_move + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf8100802 0xff5c651ffffb7c5c +writeq 0xf8100afb 0x25e000000000000 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a540000 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) +==12686==The signal is caused by a READ memory access. + #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 + #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 + #6 0x55af390ea866 in flatview_write /exec.c:3216:14 + #7 0x55af390ea387 in address_space_write /exec.c:3308:18 + #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x55af3c151261 in main /softmmu/main.c:49:5 + #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==12686==ABORTING + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890311 b/results/classifier/gemma3:12b/device/1890311 new file mode 100644 index 000000000..d411d86fe --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890311 @@ -0,0 +1,51 @@ + +Segfault in cpu_physical_memory_set_dirty_range on hppa + artist + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf810049f 0x85000000000000 +writew 0xf8118001 0x14 +writeq 0xf81005fb 0x5c00006418001832 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb40000 (pc 0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0) +==10793==The signal is caused by a READ memory access. + + #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13 + #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x5577f4c04873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23 + #6 0x5577f429a866 in flatview_write /exec.c:3216:14 + #7 0x5577f429a387 in address_space_write /exec.c:3308:18 + #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x5577f72c9474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f93ea531897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x5577f7301261 in main /softmmu/main.c:49:5 + #21 0x7f93e90b7e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x5577f41a5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==10793==ABORTING + + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890312 b/results/classifier/gemma3:12b/device/1890312 new file mode 100644 index 000000000..ccc40ec4d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890312 @@ -0,0 +1,42 @@ + +Segfault in artist_vram_read + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writew 0xf8118001 0x105a +readq 0xf900f8ff +EOF + +================================================================= +==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90ffffd0 T0) +==20118==The signal is caused by a READ memory access. + #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 + #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 + #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 + #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 + #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 + #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 + #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 + #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 + #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 + #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 + #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 + #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 + #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #16 0x7fc7261ad897 in g_main_context_dispatch () + #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 + #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 + #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 + #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #21 0x55ec9decb911 in main /softmmu/main.c:49:5 + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890333 b/results/classifier/gemma3:12b/device/1890333 new file mode 100644 index 000000000..f58d60e19 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890333 @@ -0,0 +1,24 @@ + +[OSS-Fuzz] Issue 26797: qemu:qemu-fuzz-i386-target-generic-fuzz-virtio-blk: ASSERT: addr < cache->len && 2 <= cache->len - addr + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001001 +outl 0xcfc 0x6574c1ff +outl 0xcf8 0x8000100e +outl 0xcfc 0xefe5e1e +outl 0xe86 0x3aff9090 +outl 0xe84 0x3aff9090 +outl 0xe8e 0xe +EOF + +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +Aborted + +I can trigger similar assertions with other VIRTIO devices, as-well. +I reported this at some point in Message-ID: <email address hidden> but never created a Launchpad issue... +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890360 b/results/classifier/gemma3:12b/device/1890360 new file mode 100644 index 000000000..9e670c156 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890360 @@ -0,0 +1,71 @@ + +Assertion failure in address_space_unmap through virtio-blk + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc001 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xc006 0x3aff9090 +outl 0xcf8 0x8000100e +outl 0xcfc 0x41005e1e +write 0x3b00002 0x1 0x5e +write 0x3b00004 0x1 0x5e +write 0x3aff5e6 0x1 0x11 +write 0x3aff5eb 0x1 0xc6 +write 0x3aff5ec 0x1 0xc6 +write 0x7 0x1 0xff +write 0x8 0x1 0xfb +write 0xc 0x1 0x11 +write 0xe 0x1 0x5e +write 0x5e8 0x1 0x11 +write 0x5ec 0x1 0xc6 +outl 0x410e 0x10e +EOF + + +qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +==789== ERROR: libFuzzer: deadly signal + #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 in address_space_unmap /exec.c:3623:9 + #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 + #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 + #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 + #13 in virtqueue_push /hw/virtio/virtio.c:917:5 + #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 + #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 + #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 + #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 + #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 + #19 in aio_dispatch_handler /util/aio-posix.c:328:9 + #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 + #21 in aio_dispatch /util/aio-posix.c:381:5 + #22 in aio_ctx_dispatch /util/async.c:306:5 + #23 in g_main_context_dispatch + + +With -trace virtio\* + +... +[S +0.099667] OK +[R +0.099681] write 0x5ec 0x1 0xc6 +OK +[S +0.099690] OK +[R +0.099700] outl 0x410e 0x10e +29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +OK +[S +0.099833] OK +29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. + + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1890775 b/results/classifier/gemma3:12b/device/1890775 new file mode 100644 index 000000000..f13f69e62 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1890775 @@ -0,0 +1,15 @@ + +Aten USB to Serial bridge does not work with qemu under Windows 10 + +I would like to use MSDOS 6.22 with qemu (unfortunatelly lot of our test programs has been written in dos). +I tried to connect two laptop by RS232 port, one of the machine have a built-in serial port and run with native MSDOS 6.22 with 4.0 norton commander. Another machine have only USB ports and i try to use a new Aten USB to Serial device. Ok. Has been started qemu with -serial and -chardev parameters, at startup appear a window with serial port setting such as baud rate, start bit, etc... + +Quemu has been satrted succeeded but serial port cannot be used becouse was nothing activited on usb serial adapter :( + +I tried same configuration with VirtualBox and everything was worked fine (serial connection was estabiled and copied several files from one machine into another machine), seems to be the emulated serial port has been worked fine. + +I would like to use qemu, i just thougt qemu is better, simple and faster... + +Exists solution or is this a qemu bug? + +Thank you! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1891341 b/results/classifier/gemma3:12b/device/1891341 new file mode 100644 index 000000000..3352d3d76 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1891341 @@ -0,0 +1,162 @@ + +Heap-use-after-free in usb_packet_copy through iov_to_buf + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +-trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001016 +outl 0xcfc 0x3c009f0d +outl 0xcf8 0x80001004 +outl 0xcfc 0xc77695e +writel 0x9f0d000000000040 0xffff3655 +writeq 0x9f0d000000002000 0xff2f9e0000000000 +write 0x1d 0x1 0x27 +write 0x2d 0x1 0x2e +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x06 +write 0x17278 0x1 0x34 +write 0x3d 0x1 0x27 +write 0x40 0x1 0x2e +write 0x41 0x1 0x72 +write 0x42 0x1 0x01 +write 0x4d 0x1 0x2e +write 0x4f 0x1 0x01 +writeq 0x9f0d000000002000 0x5c051a0100000000 +write 0x34001d 0x1 0x13 +write 0x340026 0x1 0x30 +write 0x340028 0x1 0x08 +write 0x34002c 0x1 0xfe +write 0x34002d 0x1 0x08 +write 0x340037 0x1 0x5e +write 0x34003a 0x1 0x05 +write 0x34003d 0x1 0x05 +write 0x34004d 0x1 0x13 +writeq 0x9f0d000000002000 0xff00010100400009 +EOF + + +Abridged trace: +... +[R +0.032356] writel 0x9f0d000000000040 0xffff3655 +4760@1597243414.491762:usb_xhci_oper_write off 0x0000, val 0xffff3655 +4760@1597243414.491765:usb_xhci_run +4760@1597243414.491769:usb_xhci_irq_intx level 0 +OK +[S +0.032371] OK +[R +0.032376] writeq 0x9f0d000000002000 0xff2f9e0000000000 +4760@1597243414.491784:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +4760@1597243414.491793:usb_xhci_fetch_trb addr 0x0000000000000000, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +4760@1597243414.491798:usb_xhci_doorbell_write off 0x0004, val 0xff2f9e00 +OK +[S +0.032400] OK +... + +[R +0.032495] writeq 0x9f0d000000002000 0x5c051a0100000000 +4760@1597243414.491899:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +4760@1597243414.491902:usb_xhci_fetch_trb addr 0x0000000000000010, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +4760@1597243414.491906:usb_xhci_slot_enable slotid 1 +4760@1597243414.491909:usb_xhci_fetch_trb addr 0x0000000000000020, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +4760@1597243414.491914:usb_xhci_fetch_trb addr 0x0000000000000030, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +4760@1597243414.491917:usb_xhci_slot_enable slotid 2 +4760@1597243414.491920:usb_xhci_fetch_trb addr 0x0000000000000040, CR_ADDRESS_DEVICE, p 0x000000000001722e, s 0x00000000, c 0x01002e00 +4760@1597243414.491925:usb_xhci_slot_address slotid 1, port 2 +4760@1597243414.491931:usb_xhci_ep_enable slotid 1, epid 1 +4760@1597243414.491937:usb_xhci_fetch_trb addr 0x0000000000000050, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +4760@1597243414.491941:usb_xhci_doorbell_write off 0x0004, val 0x5c051a01 +4760@1597243414.491945:usb_xhci_ep_kick slotid 1, epid 1, streamid 23557 +4760@1597243414.491955:usb_xhci_fetch_trb addr 0x0000000000340000, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +OK +[S +0.032563] OK +... + +OK +[S +0.032643] OK +[R +0.032648] writeq 0x9f0d000000002000 0xff00010100400009 +4760@1597243414.492052:usb_xhci_doorbell_write off 0x0000, val 0x00400009 +4760@1597243414.492055:usb_xhci_doorbell_write off 0x0004, val 0xff000101 +4760@1597243414.492058:usb_xhci_ep_kick slotid 1, epid 1, streamid 65280 +4760@1597243414.492063:usb_xhci_fetch_trb addr 0x0000000000340010, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00001300 +4760@1597243414.492067:usb_xhci_xfer_start 0x611000045140: slotid 1, epid 1, streamid 0 +4760@1597243414.492074:usb_xhci_fetch_trb addr 0x0000000000340020, TR_SETUP, p 0x0030000000000000, s 0x00000008, c 0x000008fe +4760@1597243414.492078:usb_xhci_fetch_trb addr 0x0000000000340030, TR_NORMAL, p 0x5e00000000000000, s 0x00050000, c 0x00000500 +4760@1597243414.492081:usb_xhci_fetch_trb addr 0x0000000000340040, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00001300 +4760@1597243414.492084:usb_xhci_xfer_start 0x611000045280: slotid 1, epid 1, streamid 0 +4760@1597243414.492089:usb_packet_state_change bus 0, port 2, ep 0, packet 0x611000045288, state undef -> setup +================================================================= +==4760==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000341000 at pc 0x562d20cd6847 bp 0x7ffccc326780 sp 0x7ffccc325f48 +READ of size 48 at 0x625000341000 thread T0 + #0 0x562d20cd6846 in __asan_memcpy (build/i386-softmmu/qemu-system-i386+0x250d846) + #1 0x562d22a6b374 in iov_to_buf_full util/iov.c:52:13 + #2 0x562d21ee5139 in iov_to_buf include/qemu/iov.h:62:16 + #3 0x562d21ee5139 in usb_packet_copy hw/usb/core.c:595:9 + #4 0x562d21ee96b4 in do_parameter hw/usb/core.c:284:9 + #5 0x562d21ee96b4 in usb_process_one hw/usb/core.c:369:13 + #6 0x562d21ee6ad8 in usb_handle_packet hw/usb/core.c:419:9 + #7 0x562d21f927b6 in xhci_kick_epctx hw/usb/hcd-xhci.c + #8 0x562d21fb337d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #9 0x562d212f1b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #10 0x562d212f158b in access_with_adjusted_size softmmu/memory.c:544:18 + #11 0x562d212f0d9b in memory_region_dispatch_write softmmu/memory.c + #12 0x562d20d344d2 in flatview_write_continue exec.c:3176:23 + #13 0x562d20d29e6b in flatview_write exec.c:3216:14 + #14 0x562d20d29e6b in address_space_write exec.c:3308:18 + #15 0x562d213322a9 in qtest_process_command softmmu/qtest.c:452:13 + #16 0x562d2132f087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #17 0x562d22802293 in fd_chr_read chardev/char-fd.c:68:9 + #18 0x7f6b5673b897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x562d22a821b3 in glib_pollfds_poll util/main-loop.c:217:9 + #20 0x562d22a821b3 in os_host_main_loop_wait util/main-loop.c:240:5 + #21 0x562d22a821b3 in main_loop_wait util/main-loop.c:516:11 + #22 0x562d21340008 in qemu_main_loop softmmu/vl.c:1676:9 + #23 0x562d228b10fd in main softmmu/main.c:49:5 + +0x625000341000 is located 0 bytes inside of 4096-byte region [0x625000341000,0x625000342000) +freed by thread T0 here: + #0 0x562d20cd716d in free (build/i386-softmmu/qemu-system-i386+0x250e16d) + #1 0x562d22a02242 in qemu_vfree util/oslib-posix.c:247:5 + #2 0x562d20d2d019 in address_space_unmap exec.c:3637:5 + #3 0x562d21f09bbb in dma_memory_unmap include/sysemu/dma.h:145:5 + #4 0x562d21f09bbb in usb_packet_unmap hw/usb/libhw.c:65:9 + #5 0x562d21f0966f in usb_packet_map hw/usb/libhw.c:54:5 + #6 0x562d21f985f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #7 0x562d21f92143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #8 0x562d21f92143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #9 0x562d21fb337d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #10 0x562d212f1b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #11 0x562d212f158b in access_with_adjusted_size softmmu/memory.c:544:18 + #12 0x562d212f0d9b in memory_region_dispatch_write softmmu/memory.c + #13 0x562d20d344d2 in flatview_write_continue exec.c:3176:23 + #14 0x562d20d29e6b in flatview_write exec.c:3216:14 + #15 0x562d20d29e6b in address_space_write exec.c:3308:18 + #16 0x562d213322a9 in qtest_process_command softmmu/qtest.c:452:13 + #17 0x562d2132f087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #18 0x562d22802293 in fd_chr_read chardev/char-fd.c:68:9 + #19 0x7f6b5673b897 in g_main_context_dispatch + +previously allocated by thread T0 here: + #0 0x562d20cd7ea7 in posix_memalign (build/i386-softmmu/qemu-system-i386+0x250eea7) + #1 0x562d22a01995 in qemu_try_memalign util/oslib-posix.c:207:11 + #2 0x562d22a01d48 in qemu_memalign util/oslib-posix.c:223:27 + #3 0x562d20d2c8f0 in address_space_map exec.c:3586:25 + #4 0x562d21f093cb in dma_memory_map include/sysemu/dma.h:135:9 + #5 0x562d21f093cb in usb_packet_map hw/usb/libhw.c:39:19 + #6 0x562d21f985f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #7 0x562d21f92143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #8 0x562d21f92143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #9 0x562d21fb337d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #10 0x562d212f1b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #11 0x562d212f158b in access_with_adjusted_size softmmu/memory.c:544:18 + #12 0x562d212f0d9b in memory_region_dispatch_write softmmu/memory.c + #13 0x562d20d344d2 in flatview_write_continue exec.c:3176:23 + #14 0x562d20d29e6b in flatview_write exec.c:3216:14 + #15 0x562d20d29e6b in address_space_write exec.c:3308:18 + #16 0x562d213322a9 in qtest_process_command softmmu/qtest.c:452:13 + #17 0x562d2132f087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #18 0x562d22802293 in fd_chr_read chardev/char-fd.c:68:9 + #19 0x7f6b5673b897 in g_main_context_dispatch + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1892 b/results/classifier/gemma3:12b/device/1892 new file mode 100644 index 000000000..dabb94e17 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1892 @@ -0,0 +1,34 @@ + +docs/system/devices/cxl.rst suggests qemu-system-aarch64 command lines which fail with "Property 'virt-8.2-machine.cxl' not found" +Description of problem: +When trying to run qemu-system-aarch64 with "-M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max", get the following problem: +"qemu-system-aarch64: Property 'virt-8.2-machine.cxl' not found". Do I need to compile the QEMU with specific option? +Steps to reproduce: +1. Compile QEMU with "./config" "make -j6" +2. Compile Linux +``` +#!/bin/bash + +KERNEL_PATH=/users/LiuQun/linux/arch/arm64/boot/Image +DISK_IMG=/users/LiuQun/ARM_img/disk-image-22.04-server-arm64.img + +./build/qemu-system-aarch64 \ +-M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \ +-bios /users/LiuQun/ARM_img/QEMU_EFI.fd \ +-kernel $KERNEL_PATH \ +-drive file=$DISK_IMG,format=raw,if=none,id=drive-sata0-0-0 \ +-device virtio-blk-device,drive=drive-sata0-0-0 \ +-append "console=ttyAMA0 root=/dev/vda1 rdinit=/init acpi=off" \ +-object memory-backend-file,id=cxl-mem1,share=on,mem-path=cxl-window1,size=512M \ +-object memory-backend-file,id=cxl-label1,share=on,mem-path=cxl-label1,size=1K \ +-object memory-backend-file,id=cxl-label2,share=on,mem-path=cxl-label2,size=1K \ +-device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,window-base[0]=0x4c00000000,memdev[0]=cxl-mem1 \ +-device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0,port=0 \ +-device cxl-rp,id=rp1,bus=cxl.0,addr=1.0,chassis=0,slot=1,port=1 \ +-device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M,lsa=cxl-label1 \ +-device cxl-type3,bus=rp1,memdev=cxl-mem1,id=cxl-pmem1,size=256M,lsa=cxl-label2 \ +-nographic + +``` +Additional information: +The same problem happens with QEMU 8.1 diff --git a/results/classifier/gemma3:12b/device/1892761 b/results/classifier/gemma3:12b/device/1892761 new file mode 100644 index 000000000..ece5485a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1892761 @@ -0,0 +1,11 @@ + +Heap-use-after-free through double-fetch in ehci + +Hello, +I don't have a qtest reproducer for this crash because it involves a DMA double-fetch, and I don't think we can reproduce those with qtest. + +Instead, I attached the pseudo-qtest trace produced by the fuzzer, along with some trace events. +The lines annotated with [DMA] are write commands that were triggered by a callback from a DMA read by the device. The lines annotated with [DOUBLE-FETCH] are DMA accesses that hit the same address more than once (possible double-fetches). + +I am still thinking of nicer ways of presenting this trace and providing a reproducer. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1892960 b/results/classifier/gemma3:12b/device/1892960 new file mode 100644 index 000000000..23266bd72 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1892960 @@ -0,0 +1,217 @@ + +Heap-overflow in flatview_read through sdhci_data_transfer + +Hello, +Reproducer: +cat << EOF | ./qemu-system-i386 -nodefaults \ +-device sdhci-pci,sd-spec-version=3 \ +-device sd-card,drive=mydrive \ +-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ +-nographic -qtest stdio -accel qtest +outl 0xcf8 0x80001010 +outl 0xcfc 0xd7055dba +outl 0xcf8 0x80001003 +outl 0xcfc 0x86b1d733 +writeq 0xd7055d2b 0x84126e0ed7d7355e +writeq 0xd7055d23 0x13bd7d7346e0129 +writeq 0xd7055d05 0x615bfb845e05c42c +write 0x0 0x1 0x39 +write 0x5 0x1 0x06 +write 0x6 0x1 0x35 +write 0x7 0x1 0x01 +write 0x1350600 0x1 0x39 +writew 0xd7055d0e 0x846e +write 0x1350600 0x1 0x29 +write 0x1350602 0x1 0x1a +write 0x1350608 0x1 0x39 +clock_step +writeq 0xd7055d03 0x6d00000026000000 +clock_step +EOF + +The trace: + +[R +0.077745] outl 0xcf8 0x80001010 +OK +[S +0.077773] OK +[R +0.077792] outl 0xcfc 0xd7055dba +OK +[S +0.077813] OK +[R +0.077826] outl 0xcf8 0x80001003 +OK +[S +0.077835] OK +[R +0.077846] outl 0xcfc 0x86b1d733 +OK +[S +0.080186] OK +[R +0.080204] writeq 0xd7055d2b 0x84126e0ed7d7355e +752161@1598405049.572123:sdhci_access wr8: addr[0x002b] <- 0x0000005e (94) +752161@1598405049.572133:sdhci_access wr32: addr[0x002c] <- 0x0ed7d735 (249026357) +752161@1598405049.572142:sdhci_access wr16: addr[0x0030] <- 0x0000126e (4718) +752161@1598405049.572150:sdhci_access wr8: addr[0x0032] <- 0x00000084 (132) +OK +[S +0.080255] OK +[R +0.080267] writeq 0xd7055d23 0x13bd7d7346e0129 +752161@1598405049.572176:sdhci_error Non-sequential access to Buffer Data Port registeris prohibited + +752161@1598405049.572181:sdhci_access wr8: addr[0x0023] <- 0x00000029 (41) +752161@1598405049.572187:sdhci_access wr32: addr[0x0024] <- 0xd7346e01 (3610537473) +752161@1598405049.572193:sdhci_access wr16: addr[0x0028] <- 0x00003bd7 (15319) +752161@1598405049.572200:sdhci_access wr8: addr[0x002a] <- 0x00000001 (1) +OK +[S +0.080303] OK +[R +0.080316] writeq 0xd7055d05 0x615bfb845e05c42c +752161@1598405049.572226:sdhci_access wr8: addr[0x0005] <- 0x0000002c (44) +752161@1598405049.572233:sdhci_access wr16: addr[0x0006] <- 0x000005c4 (1476) +752161@1598405049.572240:sdhci_access wr32: addr[0x0008] <- 0x5bfb845e (1543210078) +752161@1598405049.572247:sdhci_access wr8: addr[0x000c] <- 0x00000061 (97) +OK +[S +0.080350] OK +[R +0.080362] write 0x0 0x1 0x39 +OK +[S +0.080606] OK +[R +0.080617] write 0x5 0x1 0x06 +OK +[S +0.080629] OK +[R +0.080639] write 0x6 0x1 0x35 +OK +[S +0.080648] OK +[R +0.080657] write 0x7 0x1 0x01 +OK +[S +0.080665] OK +[R +0.080675] write 0x1350600 0x1 0x39 +OK +[S +0.080863] OK +[R +0.080875] writew 0xd7055d0e 0x846e +752161@1598405049.572786:sdhci_send_command CMD132 ARG[0x5bfb845e] +752161@1598405049.572810:sdhci_error timeout waiting for command response +752161@1598405049.572822:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572827:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572833:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.572837:sdhci_adma link: admasysaddr=0x0 +752161@1598405049.572842:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572845:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572851:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.572854:sdhci_adma link: admasysaddr=0x0 +752161@1598405049.572859:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572862:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572875:sdhci_access wr16: addr[0x000e] <- 0x0000846e (33902) +OK +[S +0.080979] OK +[R +0.080991] write 0x1350600 0x1 0x29 +OK +[S +0.081001] OK +[R +0.081011] write 0x1350602 0x1 0x1a +OK +[S +0.081019] OK +[R +0.081029] write 0x1350608 0x1 0x39 +OK +[S +0.081037] OK +[R +0.081045] clock_step +752161@1598405049.572962:sdhci_adma_loop addr=0x00000000, len=26, attr=0x29 +752161@1598405049.572972:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.572977:sdhci_adma link: admasysaddr=0x0 +752161@1598405049.572981:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572985:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572989:sdhci_adma_loop addr=0x00000000, len=26, attr=0x29 +752161@1598405049.572997:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.573001:sdhci_adma link: admasysaddr=0x0 +OK 100 +[S +0.081112] OK 100 +[R +0.081126] writeq 0xd7055d03 0x6d00000026000000 +752161@1598405049.573038:sdhci_access wr8: addr[0x0003] <- 0x00000000 (0) +752161@1598405049.573045:sdhci_access wr32: addr[0x0004] <- 0x00260000 (2490368) +752161@1598405049.573051:sdhci_access wr16: addr[0x0008] <- 0x00000000 (0) +752161@1598405049.573057:sdhci_access wr8: addr[0x000a] <- 0x0000006d (109) +OK +[S +0.081162] OK +[R +0.081171] clock_step +752161@1598405049.573085:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.573090:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.573096:sdhci_adma_loop addr=0x00000000, len=26, attr=0x29 +================================================================= +==752161==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500001e500 at pc 0x5651bce1a940 bp 0x7fff16a81f50 sp 0x7fff16a81718 +WRITE of size 786432 at 0x61500001e500 thread T0 + #0 0x5651bce1a93f in __asan_memcpy (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2893f) + #1 0x5651bf4197ce in flatview_read_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3246:13 + #2 0x5651bf41bff3 in flatview_read /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3279:12 + #3 0x5651bf41bb48 in address_space_read_full /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3292:18 + #4 0x5651bf41cce8 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3320:16 + #5 0x5651bd623b67 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #6 0x5651bd623585 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #7 0x5651bd6227b7 in dma_memory_read /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:116:12 + #8 0x5651bd61b052 in sdhci_do_adma /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:792:21 + #9 0x5651bd60d3c4 in sdhci_data_transfer /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:887:13 + #10 0x5651c0c4d917 in timerlist_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:572:9 + #11 0x5651c0c4de51 in qemu_clock_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:586:12 + #12 0x5651bf562a13 in qtest_clock_warp /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/cpus.c:507:9 + #13 0x5651bf74f5d8 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:665:9 + #14 0x5651bf73d63e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #15 0x5651bf73c3e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #16 0x5651c0842762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #17 0x5651c08428aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #18 0x5651c0868514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #19 0x5651c0754736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #20 0x7fac88fad4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #21 0x5651c0cdfc67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #22 0x5651c0cdd567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #23 0x5651c0cdcf47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #24 0x5651bf4bb08d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #25 0x5651bce4d51c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #26 0x7fac887b6cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #27 0x5651bcda2cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +0x61500001e500 is located 0 bytes to the right of 512-byte region [0x61500001e300,0x61500001e500) +allocated by thread T0 here: + #0 0x5651bce1b5b2 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d295b2) + #1 0x7fac88fb3210 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x56210) + #2 0x5651bd8cd222 in sdhci_pci_realize /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci-pci.c:36:5 + #3 0x5651bd88c228 in pci_qdev_realize /home/alxndr/Development/qemu/general-fuzz/build/../hw/pci/pci.c:2114:9 + #4 0x5651c07a4ec9 in device_set_realized /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:864:13 + #5 0x5651bfe384b8 in property_set_bool /home/alxndr/Development/qemu/general-fuzz/build/../qom/object.c:2202:5 + #6 0x5651bfe2c1cf in object_property_set /home/alxndr/Development/qemu/general-fuzz/build/../qom/object.c:1349:5 + #7 0x5651bfe49471 in object_property_set_qobject /home/alxndr/Development/qemu/general-fuzz/build/../qom/qom-qobject.c:28:10 + #8 0x5651bfe2d890 in object_property_set_bool /home/alxndr/Development/qemu/general-fuzz/build/../qom/object.c:1416:15 + #9 0x5651c078cc64 in qdev_realize /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:379:12 + #10 0x5651bd8bd8cc in qdev_device_add /home/alxndr/Development/qemu/general-fuzz/build/../qdev-monitor.c:676:10 + #11 0x5651bf4e3e43 in device_init_func /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:2101:11 + #12 0x5651c0af71e4 in qemu_opts_foreach /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-option.c:1172:14 + #13 0x5651bf4cd04b in qemu_init /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:4384:5 + #14 0x5651bce4d517 in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:49:5 + #15 0x7fac887b6cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2893f) in __asan_memcpy +Shadow bytes around the buggy address: + 0x0c2a7fffbc50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c2a7fffbc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffbc70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffbc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffbc90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c2a7fffbca0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c2a7fffbcb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbcc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbcd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbce0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbcf0: 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 +==752161==ABORTING + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1892963 b/results/classifier/gemma3:12b/device/1892963 new file mode 100644 index 000000000..c9e823116 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1892963 @@ -0,0 +1,316 @@ + +Heap-use-after-free in put_dwords through ehci_flush_qh + +Hello, +Reproducer: + +cat << EOF | ./qemu-system-i386 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,\ +multifunction=on,id=ich9-ehci-1 \ +-drive if=none,id=usbcdrom,media=cdrom \ +-device usb-storage,bus=ich9-ehci-1.0,\ +port=2,drive=usbcdrom \ +-display none -nodefaults -qtest stdio -accel qtest +outl 0xcf8 0x8000ef02 +outl 0xcfc 0xfbff0061 +outl 0xcf8 0x8000ef11 +outl 0xcfc 0x60606060 +writeq 0x60606065 0xb70560ff84ffff7f +writeq 0x60606065 0xff0004fe050000ff +writeq 0x60606020 0xff015e5c057b0039 +writeq 0x60606033 0x846c8a0200000611 +write 0x2000004 0x4 0x4a606060 +write 0x8 0x4 0x97a98095 +write 0x0 0x4 0x4a606060 +write 0x4 0x4 0x97a98095 +write 0xc 0x4 0x4a606060 +write 0x10 0x4 0x97a98095 +write 0x14 0x4 0x4a606060 +write 0x18 0x4 0x97a98095 +write 0x1c 0x4 0x4a606060 +clock_step +EOF + +The trace: +797726@1598407357.169284:usb_port_claim bus 0, port 2 +797726@1598407357.169585:usb_port_attach bus 0, port 2, devspeed full+high+super, portspeed high +797726@1598407357.169598:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.169608:usb_ehci_irq level 0, frindex 0x0000, sts 0x4, mask 0x0 +797726@1598407357.186943:usb_ehci_reset === RESET === +797726@1598407357.186960:usb_ehci_port_detach detach port #1, owner ehci +797726@1598407357.186968:usb_ehci_irq level 0, frindex 0x0000, sts 0x4, mask 0x0 +797726@1598407357.186976:usb_ehci_irq level 0, frindex 0x0000, sts 0x1000, mask 0x0 +797726@1598407357.186984:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.186989:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0 +[R +0.073737] outl 0xcf8 0x8000ef02 +OK +[S +0.073774] OK +[R +0.073801] outl 0xcfc 0xfbff0061 +OK +[S +0.075074] OK +[R +0.075108] outl 0xcf8 0x8000ef11 +OK +[S +0.075126] OK +[R +0.075135] outl 0xcfc 0x60606060 +OK +[S +0.076290] OK +[R +0.076317] writeq 0x60606065 0xb70560ff84ffff7f +797726@1598407357.194959:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x560ff84 +797726@1598407357.194967:usb_ehci_port_reset reset port #1 - 1 +797726@1598407357.194971:usb_ehci_port_suspend port #1 +797726@1598407357.194975:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x601183 (old: 0x1003) +OK +[S +0.076363] OK +[R +0.076377] writeq 0x60606065 0xff0004fe050000ff +797726@1598407357.195005:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x4fe05 +797726@1598407357.195011:usb_ehci_port_reset reset port #1 - 0 +797726@1598407357.195019:usb_ehci_port_detach detach port #1, owner ehci +797726@1598407357.195026:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0 +797726@1598407357.195034:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.195038:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0 +797726@1598407357.195049:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x1005 (old: 0x601183) +OK +[S +0.076439] OK +[R +0.076457] writeq 0x60606020 0xff015e5c057b0039 +797726@1598407357.195087:usb_ehci_opreg_write wr mmio 0x0020 [USBCMD] = 0x57b0039 +attempt to set frame list size -- value 8 +797726@1598407357.195097:usb_ehci_usbsts usbsts HALT 0 +797726@1598407357.195105:usb_ehci_opreg_change ch mmio 0x0020 [USBCMD] = 0x57b0031 (old: 0x80000) +797726@1598407357.195111:usb_ehci_opreg_write wr mmio 0x0024 [USBSTS] = 0xff015e5c +797726@1598407357.195117:usb_ehci_usbsts usbsts PCD 0 +797726@1598407357.195120:usb_ehci_usbsts usbsts FLR 0 +797726@1598407357.195124:usb_ehci_usbsts usbsts HSE 0 +797726@1598407357.195127:usb_ehci_irq level 0, frindex 0x0000, sts 0x0, mask 0x0 +797726@1598407357.195132:usb_ehci_opreg_change ch mmio 0x0024 [USBSTS] = 0x0 (old: 0x4) +OK +[S +0.076519] OK +[R +0.076534] writeq 0x60606033 0x846c8a0200000611 +797726@1598407357.195164:usb_ehci_opreg_write wr mmio 0x0034 [P-LIST BASE] = 0x2000006 +ehci: PERIODIC list base register set while periodic schedule + is enabled and HC is enabled +797726@1598407357.195174:usb_ehci_opreg_change ch mmio 0x0034 [P-LIST BASE] = 0x2000006 (old: 0x0) +OK +[S +0.076562] OK +[R +0.076574] write 0x2000004 0x4 0x4a606060 +OK +[S +0.076855] OK +[R +0.076869] write 0x8 0x4 0x97a98095 +OK +[S +0.077214] OK +[R +0.077225] write 0x0 0x4 0x4a606060 +OK +[S +0.077233] OK +[R +0.077242] write 0x4 0x4 0x97a98095 +OK +[S +0.077250] OK +[R +0.077258] write 0xc 0x4 0x4a606060 +OK +[S +0.077266] OK +[R +0.077274] write 0x10 0x4 0x97a98095 +OK +[S +0.077281] OK +[R +0.077289] write 0x14 0x4 0x4a606060 +OK +[S +0.077295] OK +[R +0.077304] write 0x18 0x4 0x97a98095 +OK +[S +0.077310] OK +[R +0.077325] write 0x1c 0x4 0x4a606060 +OK +[S +0.077333] OK +[R +0.077340] clock_step +OK 27462700 +[S +0.077415] OK 27462700 +797726@1598407357.196115:usb_ehci_state periodic schedule ACTIVE +797726@1598407357.196123:usb_ehci_usbsts usbsts PSS 1 +797726@1598407357.196137:usb_ehci_state periodic schedule FETCH ENTRY +797726@1598407357.196145:usb_ehci_state periodic schedule FETCH QH +797726@1598407357.196154:usb_ehci_queue_action q 0x60d0000050b0: alloc +797726@1598407357.196168:usb_ehci_opreg_read rd mmio 0x0040 [unknown] = 0x0 +797726@1598407357.196176:usb_ehci_opreg_read rd mmio 0x0044 [unknown] = 0x0 +797726@1598407357.196182:usb_ehci_opreg_read rd mmio 0x0048 [unknown] = 0x0 +797726@1598407357.196188:usb_ehci_opreg_read rd mmio 0x004c [unknown] = 0x0 +797726@1598407357.196195:usb_ehci_opreg_read rd mmio 0x0050 [unknown] = 0x0 +797726@1598407357.196201:usb_ehci_opreg_read rd mmio 0x0054 [unknown] = 0x0 +797726@1598407357.196206:usb_ehci_opreg_read rd mmio 0x0058 [unknown] = 0x0 +797726@1598407357.196211:usb_ehci_opreg_read rd mmio 0x005c [unknown] = 0x0 +797726@1598407357.196217:usb_ehci_opreg_read rd mmio 0x0060 [CONFIGFLAG] = 0x0 +797726@1598407357.196224:usb_ehci_portsc_read rd mmio 0x0044 [port 0] = 0x1000 +797726@1598407357.196230:usb_ehci_portsc_read rd mmio 0x0048 [port 1] = 0x1005 +797726@1598407357.196237:usb_ehci_portsc_read rd mmio 0x004c [port 2] = 0x1000 +797726@1598407357.196243:usb_ehci_qh_ptrs q 0x60d0000050b0 - QH @ 0x60606040: next 0x00000000 qtds 0x00000000,0x00000000,0x00000000 +797726@1598407357.196249:usb_ehci_qh_fields QH @ 0x60606040 - rl 0, mplen 0, eps 0, ep 0, dev 0 +797726@1598407357.196255:usb_ehci_qh_bits QH @ 0x60606040 - c 0, h 0, dtc 0, i 0 +797726@1598407357.196262:usb_ehci_queue_action q 0x60d0000050b0: reset +797726@1598407357.196275:usb_ehci_state periodic schedule ADVANCEQUEUE +797726@1598407357.196281:usb_ehci_state periodic schedule FETCH QTD +797726@1598407357.196300:usb_ehci_qtd_ptrs q 0x60d0000050b0 - QTD @ 0x00000000: next 0x6060604a altnext 0x9580a997 +797726@1598407357.196306:usb_ehci_qtd_fields QTD @ 0x00000000 - tbytes 5504, cpage 2, cerr 2, pid 1 +797726@1598407357.196311:usb_ehci_qtd_bits QTD @ 0x00000000 - ioc 1, active 1, halt 0, babble 1, xacterr 0 +797726@1598407357.196323:usb_ehci_packet_action q 0x60d0000050b0 p 0x611000044380: alloc +797726@1598407357.196327:usb_ehci_state periodic schedule EXECUTE +797726@1598407357.196346:usb_ehci_opreg_write wr mmio 0x004c [unknown] = 0x0 +797726@1598407357.196351:usb_ehci_opreg_change ch mmio 0x004c [unknown] = 0x0 (old: 0x0) +797726@1598407357.196359:usb_ehci_opreg_write wr mmio 0x0050 [unknown] = 0x6060604a +797726@1598407357.196363:usb_ehci_opreg_change ch mmio 0x0050 [unknown] = 0x6060604a (old: 0x0) +797726@1598407357.196370:usb_ehci_opreg_write wr mmio 0x0054 [unknown] = 0x9580a981 +797726@1598407357.196374:usb_ehci_opreg_change ch mmio 0x0054 [unknown] = 0x9580a981 (old: 0x0) +797726@1598407357.196380:usb_ehci_opreg_write wr mmio 0x0058 [unknown] = 0x1580a997 +797726@1598407357.196385:usb_ehci_opreg_change ch mmio 0x0058 [unknown] = 0x1580a997 (old: 0x0) +797726@1598407357.196392:usb_ehci_opreg_write wr mmio 0x005c [unknown] = 0x6060604a +797726@1598407357.196396:usb_ehci_opreg_change ch mmio 0x005c [unknown] = 0x6060604a (old: 0x0) +797726@1598407357.196403:usb_ehci_opreg_write wr mmio 0x0060 [CONFIGFLAG] = 0x9580a900 +797726@1598407357.196407:usb_ehci_opreg_change ch mmio 0x0060 [CONFIGFLAG] = 0x0 (old: 0x0) +797726@1598407357.196415:usb_ehci_portsc_write wr mmio 0x0044 [port 0] = 0x60606040 +797726@1598407357.196422:usb_ehci_portsc_change ch mmio 0x0044 [port 0] = 0x601040 (old: 0x1000) +797726@1598407357.196428:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x9580a997 +797726@1598407357.196432:usb_ehci_port_reset reset port #1 - 1 +797726@1598407357.196437:usb_ehci_port_suspend port #1 +797726@1598407357.196441:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x1185 (old: 0x1005) +797726@1598407357.196448:usb_ehci_portsc_write wr mmio 0x004c [port 2] = 0x6060604a +797726@1598407357.196453:usb_ehci_portsc_change ch mmio 0x004c [port 2] = 0x601040 (old: 0x1000) +797726@1598407357.196474:usb_packet_state_change bus 0, port 2, ep 0, packet 0x6110000443c0, state undef -> setup +797726@1598407357.196505:usb_ehci_opreg_write wr mmio 0x004c [unknown] = 0xbebebebe +797726@1598407357.196509:usb_ehci_opreg_change ch mmio 0x004c [unknown] = 0xbebebebe (old: 0x0) +797726@1598407357.196516:usb_ehci_opreg_write wr mmio 0x0050 [unknown] = 0xbebebebe +797726@1598407357.196520:usb_ehci_opreg_change ch mmio 0x0050 [unknown] = 0xbebebebe (old: 0x6060604a) +797726@1598407357.196527:usb_ehci_opreg_write wr mmio 0x0054 [unknown] = 0xbebebebe +797726@1598407357.196530:usb_ehci_opreg_change ch mmio 0x0054 [unknown] = 0xbebebebe (old: 0x9580a981) +797726@1598407357.196540:usb_ehci_opreg_write wr mmio 0x0058 [unknown] = 0xbebebebe +797726@1598407357.196544:usb_ehci_opreg_change ch mmio 0x0058 [unknown] = 0xbebebebe (old: 0x1580a997) +797726@1598407357.196550:usb_ehci_opreg_write wr mmio 0x005c [unknown] = 0xbebebebe +797726@1598407357.196554:usb_ehci_opreg_change ch mmio 0x005c [unknown] = 0xbebebebe (old: 0x6060604a) +797726@1598407357.196560:usb_ehci_opreg_write wr mmio 0x0060 [CONFIGFLAG] = 0xbebebebe +797726@1598407357.196563:usb_ehci_opreg_change ch mmio 0x0060 [CONFIGFLAG] = 0x0 (old: 0x0) +797726@1598407357.196569:usb_ehci_portsc_write wr mmio 0x0044 [port 0] = 0xbebebebe +797726@1598407357.196573:usb_ehci_port_suspend port #0 +797726@1598407357.196577:usb_ehci_port_resume port #0 +797726@1598407357.196580:usb_ehci_portsc_change ch mmio 0x0044 [port 0] = 0x301000 (old: 0x601040) +797726@1598407357.196586:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0xbebebebe +797726@1598407357.196590:usb_ehci_port_reset reset port #1 - 0 +797726@1598407357.196596:usb_ehci_port_detach detach port #1, owner ehci +797726@1598407357.196602:usb_ehci_queue_action q 0x60d0000050b0: free +797726@1598407357.196606:usb_ehci_queue_action q 0x60d0000050b0: cancel +797726@1598407357.196610:usb_ehci_packet_action q 0x60d0000050b0 p 0x611000044380: free +797726@1598407357.196626:usb_ehci_irq level 0, frindex 0x0008, sts 0x4004, mask 0x0 +797726@1598407357.196636:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.196642:usb_ehci_irq level 0, frindex 0x0008, sts 0x4004, mask 0x0 +797726@1598407357.196655:usb_ehci_port_suspend port #1 +797726@1598407357.196659:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x301085 (old: 0x1185) +797726@1598407357.196669:usb_ehci_portsc_write wr mmio 0x004c [port 2] = 0xbebebebe +797726@1598407357.196674:usb_ehci_port_suspend port #2 +797726@1598407357.196679:usb_ehci_port_resume port #2 +797726@1598407357.196684:usb_ehci_portsc_change ch mmio 0x004c [port 2] = 0x301000 (old: 0x601040) +797726@1598407357.196694:usb_ehci_portsc_write wr mmio 0x0050 [port 3] = 0xbebebebe +797726@1598407357.196699:usb_ehci_port_suspend port #3 +797726@1598407357.196704:usb_ehci_portsc_change ch mmio 0x0050 [port 3] = 0x301080 (old: 0x1000) +797726@1598407357.196712:usb_ehci_portsc_write wr mmio 0x0054 [port 4] = 0xbebebebe +797726@1598407357.196716:usb_ehci_port_suspend port #4 +797726@1598407357.196718:usb_ehci_portsc_change ch mmio 0x0054 [port 4] = 0x301080 (old: 0x1000) +797726@1598407357.196724:usb_ehci_portsc_write wr mmio 0x0058 [port 5] = 0xbebebebe +797726@1598407357.196729:usb_ehci_port_suspend port #5 +797726@1598407357.196733:usb_ehci_portsc_change ch mmio 0x0058 [port 5] = 0x301080 (old: 0x1000) +================================================================= +==797726==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110000443e8 at pc 0x5574af0ef59d bp 0x7fff5b343a00 sp 0x7fff5b3439f8 +READ of size 4 at 0x6110000443e8 thread T0 + #0 0x5574af0ef59c in usb_packet_unmap /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:64:28 + #1 0x5574af0ee924 in usb_packet_map /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:54:5 + #2 0x5574ae630c2f in ehci_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1376:9 + #3 0x5574ae619cfe in ehci_state_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1942:13 + #4 0x5574ae60e8d9 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2083:21 + #5 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9 + #6 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17 + #7 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5 + #8 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13 + #9 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5 + #10 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5 + #11 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc) + #12 0x5574b2339c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #13 0x5574b2337567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #14 0x5574b2336f47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #15 0x5574b0b1508d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #16 0x5574ae4a751c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #17 0x7f44ce1e5cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #18 0x5574ae3fccf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +0x6110000443e8 is located 104 bytes inside of 248-byte region [0x611000044380,0x611000044478) +freed by thread T0 here: + #0 0x5574ae4751bd in free (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d291bd) + #1 0x5574ae5e71a1 in ehci_free_packet /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:541:5 + #2 0x5574ae5e3662 in ehci_cancel_queue /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:584:9 + #3 0x5574ae5e174c in ehci_free_queue /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:611:17 + #4 0x5574ae608300 in ehci_queues_rip_device /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:674:9 + #5 0x5574ae6034ba in ehci_detach /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:732:5 + #6 0x5574af06427f in usb_detach /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:70:5 + #7 0x5574af064607 in usb_port_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:79:5 + #8 0x5574ae63af7a in ehci_port_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:993:13 + #9 0x5574b0e31de0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #10 0x5574b0e312bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #11 0x5574b0e2ef70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #12 0x5574b0a8d8a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #13 0x5574b0a76878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #14 0x5574b0a763a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #15 0x5574b0a7dff7 in address_space_unmap /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3634:9 + #16 0x5574af0f0262 in dma_memory_unmap /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:145:5 + #17 0x5574af0f0143 in usb_packet_unmap /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:65:9 + #18 0x5574af0ee924 in usb_packet_map /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:54:5 + #19 0x5574ae630c2f in ehci_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1376:9 + #20 0x5574ae619cfe in ehci_state_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1942:13 + #21 0x5574ae60e8d9 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2083:21 + #22 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9 + #23 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17 + #24 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5 + #25 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13 + #26 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5 + #27 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5 + #28 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc) + +previously allocated by thread T0 here: + #0 0x5574ae4755b2 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d295b2) + #1 0x7f44ce9e2210 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x56210) + #2 0x5574ae6175be in ehci_state_fetchqtd /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1844:13 + #3 0x5574ae60e7f1 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2073:21 + #4 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9 + #5 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17 + #6 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5 + #7 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13 + #8 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5 + #9 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5 + #10 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc) + +SUMMARY: AddressSanitizer: heap-use-after-free /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:64:28 in usb_packet_unmap +Shadow bytes around the buggy address: + 0x0c2280000820: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2280000830: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2280000840: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd + 0x0c2280000850: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2280000860: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa +=>0x0c2280000870: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd + 0x0c2280000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa + 0x0c2280000890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c22800008a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c22800008b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c22800008c0: 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 +==797726==ABORTING + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1892966 b/results/classifier/gemma3:12b/device/1892966 new file mode 100644 index 000000000..ff895ffe3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1892966 @@ -0,0 +1,79 @@ + +Null-pointer dereference in blk_bs through ide_cancel_dma_sync + +Hello, +Reproducer: +cat << EOF | ./qemu-system-i386 -M pc \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-hd,drive=disk0,bus=ide.1,unit=1 \ +-display none -nodefaults -display none -qtest stdio -accel qtest +outw 0x176 0x35b3 +outb 0x376 0x5f +outb 0x376 0x40 +outl 0xcf8 0x80000904 +outl 0xcfc 0x5c0525b7 +outb 0x176 0x0 +outl 0xcf8 0x8000091e +outl 0xcfc 0xd7580584 +write 0x187 0x1 0x34 +write 0x277 0x1 0x34 +write 0x44f 0x1 0x5c +write 0x53f 0x1 0x5c +write 0x717 0x1 0x34 +write 0x807 0x1 0x34 +write 0x9df 0x1 0x5c +write 0xbb7 0x1 0x34 +write 0xca7 0x1 0x34 +write 0xe7f 0x1 0x5c +write 0xf6f 0x1 0x5c +outb 0xd758 0x5f +outb 0xd758 0x40 +EOF + + +Trace: +[S +0.083320] OK +[R +0.083328] outb 0xd758 0x5f +OK +[S +0.084167] OK +[R +0.084183] outb 0xd758 0x40 +../block/block-backend.c:714:17: runtime error: member access within null pointer of type 'BlockBackend' (aka 'struct BlockBackend') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../block/block-backend.c:714:17 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==843136==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x5593520d8ebc bp 0x7ffc0bb9e0b0 sp 0x7ffc0bb9e010 T0) +==843136==The signal is caused by a READ memory access. +==843136==Hint: address points to the zero page. + #0 0x5593520d8ebc in blk_bs /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:714:12 + #1 0x5593520d2d07 in blk_drain /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:1715:28 + #2 0x55935096e9dc in ide_cancel_dma_sync /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/core.c:723:9 + #3 0x55934f96b9ed in bmdma_cmd_writeb /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/pci.c:298:13 + #4 0x55934fea0547 in bmdma_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/piix.c:75:9 + #5 0x55935175dde0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #6 0x55935175d2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #7 0x55935175af70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #8 0x5593513b98a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #9 0x5593513a2878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #10 0x5593513a23a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #11 0x559351803e07 in cpu_outb /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/ioport.c:60:5 + #12 0x5593516c7b6d in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:392:13 + #13 0x5593516c363e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #14 0x5593516c23e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #15 0x5593527c8762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #16 0x5593527c88aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #17 0x5593527ee514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #18 0x5593526da736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #19 0x7f3be18ef4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #20 0x559352c65c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #21 0x559352c63567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #22 0x559352c62f47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #23 0x55935144108d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #24 0x55934edd351c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #25 0x7f3be10f8cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #26 0x55934ed28cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:714:12 in blk_bs +==843136==ABORTING + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1893634 b/results/classifier/gemma3:12b/device/1893634 new file mode 100644 index 000000000..b91759e77 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1893634 @@ -0,0 +1,11 @@ + +blk_get_max_transfer() works only with sg + +blk_get_max_transfer() is supposed to be able to get the max_sectors queue limit of the scsi device on the host side and is used in both scsi-generic.c (for scsi-generic and scsi-block) and scsi-disk.c (for scsi-hd) to set/change the max_xfer_len (and opt_xfer_len in the case of scsi-generic). + +However, it only works with the sg driver in doing so. It cannot get the queue limit with the sd driver and simply returns MAX_INT. + +qemu version 5.1.0 +kernel version 5.8.5 + +Btw, is there a particular reason that it doesn't MIN_NON_ZERO against the original max_xfer_len: https://github.com/qemu/qemu/blob/v5.1.0/hw/scsi/scsi-generic.c#L172? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1894617 b/results/classifier/gemma3:12b/device/1894617 new file mode 100644 index 000000000..635bce2c9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1894617 @@ -0,0 +1,24 @@ + +qemu-i386 mmap but offset greater than 32 bits + +I don't know if it's a problem, but I did, and it bothered me for a long time. +When I use qemu-i386 and interact with the video card device,an error has occurred: + +18534 ioctl(4,DRM_IOCTL_MODE_GETENCODER,{39,0,0,0,0}) = 0 ({39,4,34,3,0}) +18534 ioctl(4,DRM_IOCTL_MODE_CREATE_DUMB,{1080,1920,32,0,0,0,0}) = 0 ({1080,1920,32,0,1,7680,8294400}) +18534 ioctl(4,DRM_IOCTL_MODE_ADDFB,{0,1920,1080,7680,32,24,1}) = 0 ({66,1920,1080,7680,32,24,1}) +18534 ioctl(4,DRM_IOCTL_MODE_MAP_DUMB,{1,0,0}) = 0 ({1,0,5543018496}) +18534 mmap2(NULL,8294400,PROT_READ|PROT_WRITE,MAP_SHARED,4,0x14a63c) = -1 errno=22 (Invalid argument) + +"5543018496" is the offset through ioctl() and it is "0x14a63c000". +In qemu： +ret = target_mmap(arg1, arg2, arg3, + target_to_host_bitmask(arg4, mmap_flags_tbl), + arg5, arg6 << MMAP_SHIFT); + +The type of "arg6" is ulong.When use qemu-i386, arg6 can't be set to "0x14a63c000".So it's wrong for my program. + +I want to find a good way to deal with this kind of problem, but I'm not very familiar with QEMU， +so I came to ask how to deal with this problem. + +Thank you！ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1894869 b/results/classifier/gemma3:12b/device/1894869 new file mode 100644 index 000000000..32d395714 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1894869 @@ -0,0 +1,21 @@ + +Chelsio T4 has old MSIX PBA offset bug + +There exists a bug with Chelsio NICs T4 that causes the following error: + +kvm: -device vfio-pci,host=0000:83:00.7,id=hostpci1.7,bus=pci.0,addr=0x11.7: vfio 0000:83:00.7: hardware reports invalid configuration, MSIX PBA outside of specified BAR + +I was working with a downstream Proxmox developer to try to fix this issue, and they provided me with the following change to make from line 1484 of hw/vfio/pci.c: + +static void vfio_msix_early_setup(VFIOPCIDevice *vdev, Error **errp) + * is 0x1000, so we hard code that here. + */ + if (vdev->vendor_id == PCI_VENDOR_ID_CHELSIO && +- (vdev->device_id & 0xff00) == 0x5800) { ++ ((vdev->device_id & 0xff00) == 0x5800 || ++ (vdev->device_id & 0xff00) == 0x1425)) { + msix->pba_offset = 0x1000; + } else if (vdev->msix_relo == OFF_AUTOPCIBAR_OFF) { + error_setg(errp, "hardware reports invalid configuration, " + +However, I found that this did not fix the issue, so the bug appears to work differently than the one that was present on the T5 NICs which has already been patched. I have attached the output of my lspci -nnkvv \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1895310 b/results/classifier/gemma3:12b/device/1895310 new file mode 100644 index 000000000..bbffdde1b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1895310 @@ -0,0 +1,100 @@ + +Heap-overflow (read) in sd_erase + +Hello, +One more bug in sd.c ... + +cat << EOF | ./qemu-system-i386 -nodefaults \ +-device sdhci-pci,sd-spec-version=3 \ +-device sd-card,drive=mydrive \ +-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ +-nographic -qtest stdio -m 64m -trace 'sd*' +outl 0xcf8 0x80001003 +outl 0xcfc 0xd735d735 +outl 0xcf8 0x80001011 +outl 0xcfc 0x3405064c +write 0x5064c2c 0x1 0xd7 +write 0x5064c0f 0x1 0xf7 +write 0x5064c05 0x1 0xd7 +write 0x5064c0a 0x1 0x84 +write 0x5064c0b 0x1 0x4c +write 0x5064c0c 0x1 0x11 +write 0x5064c0f 0x1 0xa9 +write 0x5064c0f 0x1 0x02 +write 0x5064c0f 0x1 0x03 +write 0x5064c0e 0x1 0x2c +write 0x5064c0f 0x1 0x06 +write 0x5064c0f 0x1 0xe1 +write 0x5064c0f 0x1 0x60 +write 0x5064c0f 0x1 0x26 +EOF + + +The crash: +==133840==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x607000059e78 at pc 0x55abd1d761e6 bp 0x7ffc12800630 sp 0x7ffc12800628 +READ of size 8 at 0x607000059e78 thread T0 + #0 0x55abd1d761e5 in test_bit /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitops.h:135:19 + #1 0x55abd1d6cb1e in sd_erase /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:771:13 + #2 0x55abd1d4c893 in sd_normal_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:1412:13 + #3 0x55abd1d33c5d in sd_do_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:1724:17 + #4 0x55abd20117a4 in sdbus_do_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/core.c:99:16 + #5 0x55abd27ecc90 in sdhci_send_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:326:12 + #6 0x55abd27e16ed in sdhci_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:1136:9 + #7 0x55abd43aacc0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #8 0x55abd43aa19d in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #9 0x55abd43a7e50 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #10 0x55abd3de5dc6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #11 0x55abd3dced98 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #12 0x55abd3dce8c8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #13 0x55abd3ffabbc in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:567:9 + #14 0x55abd3feb8be in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #15 0x55abd3fea663 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #16 0x55abd51cb9a2 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #17 0x55abd51cbaea in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #18 0x55abd51e6264 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #19 0x55abd515bef6 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #20 0x7fd5d58bd4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #21 0x55abd54db327 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #22 0x55abd54d8c27 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #23 0x55abd54d8607 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #24 0x55abd3d55afd in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #25 0x55abd16df67c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #26 0x7fd5d4ec0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #27 0x55abd1634e59 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d3ee59) + +0x607000059e78 is located 0 bytes to the right of 72-byte region [0x607000059e30,0x607000059e78) +allocated by thread T0 here: + #0 0x55abd16ad712 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2db7712) + #1 0x55abd1d75464 in bitmap_try_new /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitmap.h:96:12 + #2 0x55abd1d74bd4 in bitmap_new /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitmap.h:101:26 + #3 0x55abd1d67b68 in sd_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:576:21 + #4 0x55abd47f34b2 in device_transitional_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:1114:9 + #5 0x55abd47f8ca9 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:182:13 + #6 0x55abd47afdbd in bus_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/bus.c:94:9 + #7 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #8 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #9 0x55abd47ec5f8 in device_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:358:9 + #10 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #11 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #12 0x55abd47afdbd in bus_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/bus.c:94:9 + #13 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #14 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #15 0x55abd47ec5f8 in device_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:358:9 + #16 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #17 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #18 0x55abd47afdbd in bus_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/bus.c:94:9 + #19 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #20 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #21 0x55abd47f6b28 in resettable_assert_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:60:5 + #22 0x55abd47f68cf in resettable_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:45:5 + #23 0x55abd47fb779 in resettable_cold_reset_fn /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:269:5 + #24 0x55abd47f67e5 in qemu_devices_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/reset.c:69:9 + #25 0x55abd35a5c1e in pc_machine_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/i386/pc.c:1901:5 + #26 0x55abd3d52d9e in qemu_system_reset /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1403:9 + #27 0x55abd3d67d2e in qemu_init /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:4458:5 + #28 0x55abd16df677 in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:49:5 + #29 0x7fd5d4ec0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitops.h:135:19 in test_bit + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1895602 b/results/classifier/gemma3:12b/device/1895602 new file mode 100644 index 000000000..a87381dd0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1895602 @@ -0,0 +1,12 @@ + +older OS's do not detect CD change + +There are at least two older operating systems, being FreeBSD 2.2 and FreeDOS 1.2, that misbehave when the change command is used on the IDE CD drive, and work fine on a real machine. In both cases, changing the CD causes the guest to either refuse to read the disc or appear to read bad data, and in both cases the guest read the disc without issue after a system_reset. + +A HD image that demonstrates this behavior can be produced if necessary, however the FreeDOS 1.2 CD can be booted directly and used to test: + +http://freedos.org/download/download/FD12CD.iso + +(choose install then abort and you get a prompt in which you can type "dir D:", say) + +note, running eject before the change command does nothing to help. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1896342 b/results/classifier/gemma3:12b/device/1896342 new file mode 100644 index 000000000..e332e0336 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1896342 @@ -0,0 +1,24 @@ + +IDE ATA IDENTIFY WORD 106 + +The code at line 202 in hw/ide/core.c + (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201) +hard codes bit 13 set. However, get_physical_block_exp() can and may return 0, which is a valid response. If get_physical_block_exp() does return zero, bit 13 should not be set. + +ATAPI8 states (Section 7.17.7.73): + "Bit 13 of word 106 shall be set to one to indicate that the device has more than one logical sector per physical sector" + +and gives the examples: + Bits (3:0): 0 = 2^0 = 1 logical sector per physical sector + Bits (3:0): 1 = 2^1 = 2 logical sector per physical sector + Bits (3:0): 2 = 2^2 = 4 logical sector per physical sector + Bits (3:0): 3 = 2^3 = 8 logical sector per physical sector + +Therefore, if bit 13 is set, bits 3:0 must be greater than zero. + +If get_physical_block_exp() returns zero then there is a 1:1 ratio and bit 13 must be 0. + +Just my opinion. + +Thanks, +Ben \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1897481 b/results/classifier/gemma3:12b/device/1897481 new file mode 100644 index 000000000..7efae4596 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1897481 @@ -0,0 +1,98 @@ + +qemu crashes with VGA pass-through, e-GPU, nvidia 1060 + +I try to pass-through nvidia 1060 6gb card, which is connected via ExpressCard (EXP-GDC converter). + +I can successfully run my virtual machine without pass-through, but when I try to add the devices, qemu crashes. + +The coredump contains: + +Stack trace of thread 3289311: +#0 0x0000000000614c49 memory_region_update_container_subregions (qemu-system-x86_64 + 0x214c49) +#1 0x00000000005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 0x1c0e8c) +#2 0x00000000005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0) +#3 0x000000000079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423) +#4 0x00000000006facda device_set_realized (qemu-system-x86_64 + 0x2facda) +#5 0x0000000000887e57 property_set_bool (qemu-system-x86_64 + 0x487e57) +#6 0x000000000088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48) +#7 0x000000000088d1d2 object_property_set_qobject (qemu-system-x86_64 + 0x48d1d2) +#8 0x000000000088b1f7 object_property_set_bool (qemu-system-x86_64 + 0x48b1f7) +#9 0x0000000000693785 qdev_device_add (qemu-system-x86_64 + 0x293785) +#10 0x000000000061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0) +#11 0x000000000098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b) +#12 0x00000000006211cb qemu_init (qemu-system-x86_64 + 0x2211cb) +#13 0x00000000005002aa main (qemu-system-x86_64 + 0x1002aa) +#14 0x00007fce8af21152 __libc_start_main (libc.so.6 + 0x28152) +#15 0x000000000050087e _start (qemu-system-x86_64 + 0x10087e) + +The whole running command is pretty long, since I use libvirt to manage my machines: + +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-Win10 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \ +QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu-system-x86_64 \ +-name guest=Win10,debug-threads=on \ +-S \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \ +-m 8192 \ +-overcommit mem-lock=off \ +-smp 2,sockets=2,cores=1,threads=1 \ +-uuid 7043c77b-4903-4527-8089-9679d9a17fee \ +-no-user-config \ +-nodefaults \ +-chardev stdio,mux=on,id=charmonitor \ +-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 pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +-blockdev '{"driver":"file","filename":"/home/sergiy/VirtualBox VMs/win4games.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}' \ +-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 \ +-blockdev '{"driver":"file","filename":"/home/sergiy/Downloads/Win10_2004_Ukrainian_x64.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \ +-device ide-cd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1 \ +-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 \ +-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 \ +-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 vfio-pci,host=0000:04:00.0,id=hostdev0,bus=pci.4,multifunction=on,addr=0x0 \ +-device vfio-pci,host=0000:04:00.1,id=hostdev1,bus=pci.4,addr=0x0.0x1 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on + +I've forced vfio_pci module for the VGA, and ensured that lspci shows + + Kernel driver in use: vfio_pci + +My laptop is Thinkpad x230, that runs on Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz. +I run 5.8.6-1-MANJARO kernel and run QEMU emulator version 5.1.0. + +Thank you for your attention. I'd love to provide more information, but I don't know what else matters. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1900122 b/results/classifier/gemma3:12b/device/1900122 new file mode 100644 index 000000000..6efacb979 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1900122 @@ -0,0 +1,111 @@ + +Unsupported ioctl: cmd=0xffffffff80685600 when accessing /dev/video* in aarch64 guest + +**Description:** +Any attempt to work with video in aarch64 architecture emulated on x86_64 leads currently to the error "Function not implemented". For example: + +``` +# v4l2-ctl -l --verbose +Failed to open /dev/video0: Function not implemented + +root@12dd9b6fcfcb:/# ll /dev/video* +crw-rw---- 1 root video 81, 0 Oct 16 09:23 /dev/video0 +crw-rw---- 1 root video 81, 1 Oct 16 09:23 /dev/video1 + +``` + +**Steps to reproduce the issue:** + +I have a following setup: + +Host Hardware: x86_64 equipped with a webcam (tried different webcams) +Host OS: Ubuntu 20.04.1 + +Guest Architecture: aarch64 +Guest OS: Ubuntu 20.04 (also tried 16.x and 18.x) + +Emulation: quemu-user-static (also tried binfmt) + +Guest OS is running via Docker + QEMU + +``` +➜ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 +enabled +interpreter /usr/bin/qemu-aarch64-static +flags: F +offset 0 +magic 7f454c460201010000000000000000000200b700 +mask ffffffffffffff00fffffffffffffffffeffffff +``` + +**Results received:** +see desrciption. + +**Environment:** + +<!-- The host architecture is available for only x86_64 --> +* QEMU version: (if you can know it): + +ipxe-qemu-256k-compat-efi-roms/focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/focal-updates,now 1.0.0+git-20190109.133f4c4-0ubuntu3.2 all [installed,automatic] +qemu-block-extra/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-kvm/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] +qemu-system-common/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-system-data/focal-updates,now 1:4.2-3ubuntu6.7 all [installed,automatic] +qemu-system-gui/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-system-x86/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-user-binfmt/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-user/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] +qemu-utils/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] + +* Container application: Docker + +**Output of `docker version`, `podman version` or `singularity version`** + +``` +➜ docker version +Client: Docker Engine - Community + Version: 20.10.0-beta1 + API version: 1.40 + Go version: go1.13.15 + Git commit: ac365d7 + Built: Tue Oct 13 18:15:22 2020 + OS/Arch: linux/amd64 + Context: default + Experimental: true + +Server: Docker Engine - Community + Engine: + Version: 19.03.13 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.15 + Git commit: 4484c46d9d + Built: Wed Sep 16 17:01:20 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.4.1 + GitCommit: c623d1b36f09f8ef6536a057bd658b3aa8632828 + runc: + Version: 1.0.0-rc92 + GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff + docker-init: + Version: 0.18.0 + GitCommit: fec3683 + +``` + +Guest aarch64 runs in privileged mode: + +`docker run --privileged --device=/dev/video0:/dev/video0 --env DISPLAY=unix$DISPLAY -v $XAUTH:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix -it --rm arm64v8/ubuntu:20.04 bash` + +**Additional information:** +I tried also binfmt way to register emulators. The output of `v4l-ctl` was a little bit different: + +``` +# v4l2-ctl -l +Unsupported ioctl: cmd=0xffffffff80685600 +Failed to open /dev/video0: Function not implemented + +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1900155 b/results/classifier/gemma3:12b/device/1900155 new file mode 100644 index 000000000..2a60f71db --- /dev/null +++ b/results/classifier/gemma3:12b/device/1900155 @@ -0,0 +1,59 @@ + +MIPS Malta fails booting due to IDE error + +As of commit 3e407488349: + +$ avocado --show=console run -t machine:malta tests/acceptance/boot_linux_console.py +console: [ 0.000000] Linux version 4.5.0-2-4kc-malta (<email address hidden>) (gcc version 5.3.1 20160519 (Debian 5.3.1-20) ) #1 Debian 4.5.5-1 (2016-05-29) +console: [ 0.000000] earlycon: Early serial console at I/O port 0x3f8 (options '38400n8') +console: [ 0.000000] bootconsole [uart0] enabled +console: [ 0.000000] CPU0 revision is: 00019300 (MIPS 24Kc) +console: [ 0.000000] FPU revision is: 00739300 +console: [ 0.000000] MIPS: machine is mti,malta +[...] +console: ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 +console: ata2.00: Drive reports diagnostics failure. This may indicate a drive +console: ata2.00: fault or invalid emulation. Contact drive vendor for information. +console: ata2.00: configured for UDMA/33 +console: scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +console: Freeing unused kernel memory: 412K (80979000 - 809e0000) +console: do_page_fault(): sending SIGSEGV to mount for invalid write access to 0018a000 +console: epc = 775cca54 in libc-2.27.so[775b3000+177000] +console: ra = 77754618 in ld-2.27.so[77743000+24000] +console: do_page_fault(): sending SIGSEGV to klogd for invalid write access to 0018a000 +console: epc = 770f0a54 in libc-2.27.so[770d7000+177000] +console: ra = 77278618 in ld-2.27.so[77267000+24000] +console: do_page_fault(): sending SIGSEGV to S20urandom for invalid write access to 0018a000 +console: epc = 77d0ca54 in libc-2.27.so[77cf3000+177000] +console: ra = 77e94618 in ld-2.27.so[77e83000+24000] +console: do_page_fault(): sending SIGSEGV to mkdir for invalid write access to 0018a000 +console: epc = 776b8a54 in libc-2.27.so[7769f000+177000] +console: ra = 77840618 in ld-2.27.so[7782f000+24000] +console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 0018a000 +console: epc = 77364a54 in libc-2.27.so[7734b000+177000] +console: ra = 774ec618 in ld-2.27.so[774db000+24000] +console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 0018a000 +console: epc = 77bd4a54 in libc-2.27.so[77bbb000+177000] +console: ra = 77d5c618 in ld-2.27.so[77d4b000+24000] +console: do_page_fault(): sending SIGSEGV to awk for invalid write access to 0018a000 +console: epc = 76f44a54 in libc-2.27.so[76f2b000+177000] +console: ra = 770cc618 in ld-2.27.so[770bb000+24000] +console: do_page_fault(): sending SIGSEGV to cat for invalid write access to 0018a000 +console: epc = 770cca54 in libc-2.27.so[770b3000+177000] +console: ra = 77254618 in ld-2.27.so[77243000+24000] +$ echo $? +8 + +55adb3c45620c31f29978f209e2a44a08d34e2da is the first bad commit +commit 55adb3c45620c31f29978f209e2a44a08d34e2da +Author: John Snow <email address hidden> +Date: Fri Jul 24 01:23:00 2020 -0400 + + ide: cancel pending callbacks on SRST + + The SRST implementation did not keep up with the rest of IDE; it is + possible to perform a weak reset on an IDE device to remove the BSY/DRQ + bits, and then issue writes to the control/device registers which can + cause chaos with the state machine. + + Fix that by actually performing a real reset. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1900918 b/results/classifier/gemma3:12b/device/1900918 new file mode 100644 index 000000000..a65a40ae4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1900918 @@ -0,0 +1,15 @@ + +PXB devices + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1900919 b/results/classifier/gemma3:12b/device/1900919 new file mode 100644 index 000000000..ce2fd9d88 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1900919 @@ -0,0 +1,15 @@ + +PXB selected as root bus incorrectly + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1901068 b/results/classifier/gemma3:12b/device/1901068 new file mode 100644 index 000000000..c9ff69365 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1901359 b/results/classifier/gemma3:12b/device/1901359 new file mode 100644 index 000000000..88507e9e3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1901359 @@ -0,0 +1,23 @@ + +ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access + +I'v recently stumbled upon a bug in the Plan9 PCI config space access routines for config mode #1. + +The code used to set bit 0 in the CONFIG_ADDRESS register for a Type 1 access. + +This was most likely a misreading of the PCI local bus specification on our side. + +However, in the PCI local bus specification 3.0, it states the following: + +> 3.2.2.3.2 Software Generation of Configuration Transactions +> ... +> For Type 1 translations, the host bridge directly copies the contents of the +> CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines during the +> address phase of a configuration transaction making sure that AD[1::0] is "01". + +note the: "excluding bits 31 and 0" + +What happens in qemu instead is that it uses bit 0 of the CONFIG_ADDRESS +register as part of the register offset (when it probably should ignore it) +when translating from Type 1 to Type 0 address. So once it reaches the device +behind the bridge the register address is off by one. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1901440 b/results/classifier/gemma3:12b/device/1901440 new file mode 100644 index 000000000..8c132cf50 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1901440 @@ -0,0 +1,18 @@ + +Instability in IVSHMEM after updating QEMU 4.2 -> 5.0 + +Updating Ubuntu from 20.08 to 20.10 which updates QEMU from 4.2 to 5.0 results in the virtual machines freezing when the IVSHMEM interface is active. This workstation typically runs several windows 10 virtual machines that are accessed locally: two using the spice viewer and one that uses an passthrough assigned GPU accessed through a viewer called Looking Glass. Looking Glass uses the IVSHMEM device interface to pass captured frames from the windows virtual machine to the linux host for display by a viewer application. + +This workstation was 100% stable under Ubuntu 20.08 (QEMU 4.2). It handled a variety of heavy loads all day it never froze or crashed. It became unstable under Ubuntu 20.10 (QEMU 5.0), seemingly triggered by high levels of SHM activity. I was able to reliably reproduce the problem when playing a video in the looking-glass vm while playing another video in a spice vm. Other scenarios would also trigger this problem less reliably, but this video playback scenario would trigger it after 3-5 minutes of playback. + +The result of this new instability would manifest itself by all running vms on the host freezing but the host was not visibly effected. I could find no warnings or errors in any relevant system or QEMU logs. It wasn't just spice, when I accessed the gpu-passthru vm via directly assigned devices it was frozen, still outputting video of the last frame before the crash. All vms would have to be force-shutdown and the host rebooted to regain vm functionality. Just forcing shutdown and restarting a vm would result in showing 'running' status but it would be frozen and inaccessible until system reboot. + +I suspect this is a QEMU host / kernel error for several reasons: Having to reboot the host, insensitivity to VM changes including virtio-win version, etc. I suspect it's related to IVSHMEM due to the correlation of the freeze to the looking-glass related activity. + +This might be kernel / PCIe / power management related in some way. While experimenting to troubleshoot this issue I was able to trigger the error more quickly by disabling PCIe power management in the BIOS. + +The system was 100% stable under QEMU 5.0 when not running the looking-glass vm, quite stable when the looking-glass vm was idle or lightly used, but appeared increasingly unstable as SHM activity increased. + +Sorry if this is a bit anecdotal, this is my work machine and unfortunately today I was forced to rollback restore to Ubuntu 20.08 (QEMU 4.2) from backup so I can work on Monday. The system returned to 100% stability after returning to 20.08. + +If requested I can restore the Ubuntu 20.10 snapshot to reproduce & gather information as directed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1901981 b/results/classifier/gemma3:12b/device/1901981 new file mode 100644 index 000000000..1aa597341 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1901981 @@ -0,0 +1,20 @@ + +assert issue locates in hw/usb/dev-storage.c:248: usb_msd_send_status + +Hello, + +I found an assertion failure through hw/usb/dev-storage.c. + +This was found in latest version 5.1.0. + +-------- + +qemu-system-x86_64: hw/usb/dev-storage.c:248: usb_msd_send_status: Assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed. +[1] 29544 abort sudo -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic + +To reproduce the assertion failure, please run the QEMU with following command line. + + +$ qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic user,model=rtl8139,hostfwd=tcp:0.0.0.0:5555-:22 -device piix4-usb-uhci,id=uhci -device usb-storage,drive=mydrive -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none + +The poc is attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1902112 b/results/classifier/gemma3:12b/device/1902112 new file mode 100644 index 000000000..5e9912acc --- /dev/null +++ b/results/classifier/gemma3:12b/device/1902112 @@ -0,0 +1,44 @@ + +[OSS-Fuzz] Issue 26693: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci: Index-out-of-bounds in xhci_runtime_write + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26693 + +=== Reproducer (build with --enable-sanitizers) === +export UBSAN_OPTIONS="print_stacktrace=1:silence_unsigned_overflow=1" +cat << EOF | ./qemu-system-i386 -display none -machine\ + accel=qtest, -m 512M -machine q35 -nodefaults -drive\ + file=null-co://,if=none,format=raw,id=disk0 -device\ + qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0\ + -device usb-bot -device usb-storage,drive=disk0\ + -chardev null,id=cd0 -chardev null,id=cd1 -device\ + usb-braille,chardev=cd0 -device usb-ccid -device\ + usb-ccid -device usb-kbd -device usb-mouse -device\ + usb-serial,chardev=cd1 -device usb-tablet -device\ + usb-wacom-tablet -device usb-audio -qtest stdio +outl 0xcf8 0x80000803 +outl 0xcfc 0x18caffff +outl 0xcf8 0x80000810 +outl 0xcfc 0x555a2e46 +write 0x555a1004 0x4 0xe7b9aa7a +EOF + +=== Stack Trace === + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/hcd-xhci.c:3012:30 in +../hw/usb/hcd-xhci.c:3012:30: runtime error: index -1 out of bounds for type 'XHCIInterrupter [16]' +#0 0x55bd2e97c8b0 in xhci_runtime_write /src/qemu/hw/usb/hcd-xhci.c:3012:30 +#1 0x55bd2edfdd13 in memory_region_write_accessor /src/qemu/softmmu/memory.c:484:5 +#2 0x55bd2edfdb14 in access_with_adjusted_size /src/qemu/softmmu/memory.c:545:18 +#3 0x55bd2edfd54b in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#4 0x55bd2ed7fa46 in flatview_write_continue /src/qemu/softmmu/physmem.c:2767:23 +#5 0x55bd2ed7cac0 in flatview_write /src/qemu/softmmu/physmem.c:2807:14 +#6 0x55bd2ed7c9f8 in address_space_write /src/qemu/softmmu/physmem.c:2899:18 +#7 0x55bd2e85cf9b in __wrap_qtest_writeq /src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9 +#8 0x55bd2e85b7b1 in op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:476:13 +#9 0x55bd2e85a84c in generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:678:17 +#10 0x55bd2e85dd6f in LLVMFuzzerTestOneInput /src/qemu/tests/qtest/fuzz/fuzz.c:150:5 +#11 0x55bd2e7e9661 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:595:15 +#12 0x55bd2e7d4732 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6 +#13 0x55bd2e7da7ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:852:9 +#14 0x55bd2e8027d2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 +#15 0x7f3d153b783f in __libc_start_main \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1902262 b/results/classifier/gemma3:12b/device/1902262 new file mode 100644 index 000000000..c320a14da --- /dev/null +++ b/results/classifier/gemma3:12b/device/1902262 @@ -0,0 +1,20 @@ + +vmstate_load_state return error into virtio_load function + +Qemu version 4.2.1 + +In the function of virtio_load, the vmstate_load_state will return error in the following case. + +The virtio is legacy mode(disable-modern=on,disable-legacy=off), virtio_device is in reset state. + +In the the function of "vmstate_load_state", it will load all subsection. For the vmstate_virtio_extra_state subsection. +It will execute: +vmstate_load_state --> + ret = field->info->get(f, curr_elem, size, field); line 143 vmstate.c. + -->virtio_pci_load_extra_state + --> vmstate_load_state + -->qemu_peek_byte +But if the f->buf_index is same with buf_size, qemu_peek_byte function will set "-EIO" error. +the field->info->get will return 0, then it will get the error "ret = qemu_file_get_error(f);". then the vmstate_load_state will return error. + +It output is "Failed to load virtio/extra_state:extra_state" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1902306 b/results/classifier/gemma3:12b/device/1902306 new file mode 100644 index 000000000..d36e248ed --- /dev/null +++ b/results/classifier/gemma3:12b/device/1902306 @@ -0,0 +1,11 @@ + +Allow setting usb storage device ID parameters + +Some stubborn software requires certain VID/PID/Serial to authenticate and refuses to start in emulation. This poses a problem with unsupported programs which often require keeping an ancient hardware praying that the USB stick will not die before the (often defunct) company making it. + +Virtualizing such environment is desired. However, QEMU doesn't allow setting VID/PID/Serial/Name of emulated USB devices, but instead uses hardcoded values: https://github.com/qemu/qemu/blob/c99fa56b95a72f6debd50a280561895d078ae020/hw/usb/dev-storage.c#L95 + +This request (including a patch) was already made in 2015 on the list but never got any response: https://lists.nongnu.org/archive/html/qemu-discuss/2015-07/msg00072.html + + +WDYT of adding such functionality? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1902612 b/results/classifier/gemma3:12b/device/1902612 new file mode 100644 index 000000000..322bd625e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1902612 @@ -0,0 +1,46 @@ + +assert issue locates in xhci_kick_epctx() in hw/usb/hcd-xhci.c + +Hello, + +I found an assertion failure through hw/usb/hcd-xhci.c. + +This was found in latest version 5.1.0. + +An assertion-failure flaw was found in xhci_kick_epctx() in hw/usb/hcd-xhci.c . XHCI slot's endpoint context is enabled in xhci_configure_slot(), whose ep_ctx structure is controlled by user. With uninitialized endPoint context could trigger assert(ring->dequeue != 0). The guest system could use this flaw to crash the qemu resulting in denial of service. + +To reproduce the assertion failure, please run the QEMU with following command line. + +$ qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic user,model=rtl8139,hostfwd=tcp:0.0.0.0:5555-:22 -device nec-usb-xhci,id=xhci -device usb-tablet,bus=xhci.0,port=1,id=usbdev1 + +The poc is attached. + +Backtrace is as follows: +#0 0x00007f6dfd4c4f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f6dfd4c68b1 in __GI_abort () at abort.c:79 +#2 0x00007f6dfd4b642a in __assert_fail_base (fmt=0x7f6dfd63da38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55e9b9d38a64 "ring->dequeue != 0", file=file@entry=0x55e9b9d388c0 "hw/usb/hcd-xhci.c", line=line@entry=0x7a3, function=function@entry=0x55e9b9d3a5c0 <__PRETTY_FUNCTION__.29754> "xhci_kick_epctx") at assert.c:92 +#3 0x00007f6dfd4b64a2 in __GI___assert_fail (assertion=assertion@entry=0x55e9b9d38a64 "ring->dequeue != 0", file=file@entry=0x55e9b9d388c0 "hw/usb/hcd-xhci.c", line=line@entry=0x7a3, function=function@entry=0x55e9b9d3a5c0 <__PRETTY_FUNCTION__.29754> "xhci_kick_epctx") at assert.c:101 +#4 0x000055e9b9a3292f in xhci_kick_epctx (epctx=0x7f6da836b510, streamid=streamid@entry=0x0) at hw/usb/hcd-xhci.c:1955 +#5 0x000055e9b9a3c64b in xhci_kick_ep (streamid=0x0, epid=0x1, slotid=0x11, xhci=0x7f6df8b38010) at hw/usb/hcd-xhci.c:1861 +#6 0x000055e9b9a3c64b in xhci_doorbell_write (ptr=0x7f6df8b38010, reg=0x11, val=0x1, size=<optimized out>) at hw/usb/hcd-xhci.c:3162 +#7 0x000055e9b977d274 in memory_region_write_accessor (mr=0x7f6df8b38d80, addr=0x44, value=<optimized out>, size=0x1, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:483 +#8 0x000055e9b977ad86 in access_with_adjusted_size (addr=addr@entry=0x44, value=value@entry=0x7f6dfb915f88, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55e9b977d1f0 <memory_region_write_accessor>, mr=0x7f6df8b38d80, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:544 +#9 0x000055e9b977f4c8 in memory_region_dispatch_write (mr=mr@entry=0x7f6df8b38d80, addr=0x44, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:1483 +#10 0x000055e9b972c691 in flatview_write_continue (fv=fv@entry=0x7f6da951f750, addr=addr@entry=0xfebf2044, attrs=..., ptr=ptr@entry=0x7f6dfb9160e0, len=len@entry=0x1, addr1=<optimized out>, l=<optimized out>, mr=0x7f6df8b38d80) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/exec.c:3137 +#11 0x000055e9b972c826 in flatview_write (fv=0x7f6da951f750, addr=0xfebf2044, attrs=..., buf=buf@entry=0x7f6dfb9160e0, len=0x1) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/exec.c:3177 +#12 0x000055e9b972c89a in subpage_write (opaque=<optimized out>, addr=<optimized out>, value=<optimized out>, len=<optimized out>, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/exec.c:2789 +#13 0x000055e9b977b269 in memory_region_write_with_attrs_accessor (mr=0x7f6da9534650, addr=0x44, value=<optimized out>, size=0x1, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:503 +#14 0x000055e9b977ad86 in access_with_adjusted_size (addr=addr@entry=0x44, value=value@entry=0x7f6dfb9161f8, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55e9b977b1e0 <memory_region_write_with_attrs_accessor>, mr=0x7f6da9534650, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:544 +#15 0x000055e9b977f4c8 in memory_region_dispatch_write (mr=0x7f6da9534650, addr=addr@entry=0x44, data=<optimized out>, data@entry=0x1, op=op@entry=MO_8, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:1483 +#16 0x000055e9b979021f in io_writex (env=env@entry=0x55e9baed5b50, iotlbentry=iotlbentry@entry=0x7f6da8b8bc10, mmu_idx=mmu_idx@entry=0x1, val=val@entry=0x1, addr=addr@entry=0x7fbba0601044, retaddr=retaddr@entry=0x7f6db9d90d48, op=MO_8) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cputlb.c:1084 +#17 0x000055e9b9794c42 in store_helper (op=MO_8, retaddr=0x7f6db9d90d48, oi=<optimized out>, val=<optimized out>, addr=0x7fbba0601044, env=0x55e9baed5b50) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cputlb.c:1954 +#18 0x000055e9b9794c42 in helper_ret_stb_mmu (env=0x55e9baed5b50, addr=0x7fbba0601044, val=0x1, oi=<optimized out>, retaddr=0x7f6db9d90d48) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cputlb.c:2056 +#19 0x00007f6db9d90d48 in code_gen_buffer () +#20 0x000055e9b97a5217 in cpu_tb_exec (itb=<optimized out>, cpu=0x7f6db9d240c0 <code_gen_buffer+97665171>) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cpu-exec.c:172 +#21 0x000055e9b97a5217 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7f6db9d240c0 <code_gen_buffer+97665171>) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cpu-exec.c:619 +#22 0x000055e9b97a5217 in cpu_exec (cpu=cpu@entry=0x55e9baecd2f0) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cpu-exec.c:732 +#23 0x000055e9b976ff9f in tcg_cpu_exec (cpu=0x55e9baecd2f0) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/cpus.c:1405 +#24 0x000055e9b97723cb in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x55e9baecd2f0) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/cpus.c:1713 +#25 0x000055e9b9be7d66 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:519 +#26 0x00007f6dfd87e6db in start_thread (arg=0x7f6dfb917700) at pthread_create.c:463 +#27 0x00007f6dfd5a7a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1904490 b/results/classifier/gemma3:12b/device/1904490 new file mode 100644 index 000000000..1cdf921dd --- /dev/null +++ b/results/classifier/gemma3:12b/device/1904490 @@ -0,0 +1,25 @@ + +intel-hda: valid registers are unknown + +According to HDA specification, "3.1.2 General Register Behaviors and Access Requirements": + +"All controller registers must be addressable as byte, Word, and Dword quantities." + +But e.g. if you try the following to reset and enable the CORB, assuming es:esi contains the base MMIO address of the controller, + + es or [esi+4bh], byte 80h ; reset CORB +corbresetloop: + es test [esi+4bh], byte 80h ; is HW done resetting yet? + jnz corbreset1ok ; yes, bit is now 1 + hlt ; wait a little bit + jmp corbresetloop ; and check again +corbreset1ok: + es and [esi+4bh], byte 7fh ; clear the bit + +It will hang indefinitely because the bit never gets set, and if you enable debug output of the controller with "-device intel-hda,debug=1", you will see infinitely the line "unknown register, addr 0x4b" output. The same code on a real hardware (I tried with ICH7M) works fine, as it should according to the spec. + +Host/guest/version does not matter (I am writing own drivers) --- as of right now, latest version still has this code: + +https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c + +which seems to emit "unknown register" message in intel_hda_reg_find(), and this function does not take into account range of addresses that each register occupies. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1904652 b/results/classifier/gemma3:12b/device/1904652 new file mode 100644 index 000000000..1961c42a8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1904652 @@ -0,0 +1,51 @@ + +Assertion failure in usb-ohci + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ohci. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + +-------- + +``` + +Program terminated with signal SIGABRT, Aborted. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7f34d0411440 (LWP 9418))] +gdb-peda$ bt +#0 0x00007f34c8d4ef47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f34c8d508b1 in __GI_abort () at abort.c:79 +#2 0x000055d3a2081844 in ohci_frame_boundary (opaque=0x55d3a4ecdaf0) at ../hw/usb/hcd-ohci.c:1297 +#3 0x000055d3a25be155 in timerlist_run_timers (timer_list=0x55d3a3fd9840) at ../util/qemu-timer.c:574 +#4 0x000055d3a25beaba in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#5 0x000055d3a25beaba in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#6 0x000055d3a25e69a1 in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531 +#7 0x000055d3a2433972 in qemu_main_loop () at ../softmmu/vl.c:1678 +#8 0x000055d3a1d0969b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, + argv@entry=0x7ffc6de722a8, envp=<optimized out>) at ../softmmu/main.c:50 +#9 0x00007f34c8d31b97 in __libc_start_main (main= + 0x55d3a1d09690 <main>, argc=0x15, argv=0x7ffc6de722a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc6de72298) at ../csu/libc-start.c:310 +#10 0x000055d3a1d095aa in _start () +``` + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` +[Terminal 1] + +$ qemu-system-i386 -m 512 -drive file=./fs.img,index=1,media=disk,format=raw -drive file=./hyfuzz.img,index=0,media=disk,format=raw -drive if=none,id=stick,file=./usbdisk.img,format=raw -device pci-ohci,id=usb -device usb-storage,bus=usb.0,drive=stick + +[Terminal 2] + +$ ./repro_log ./fs.img ./pci-ohci + +``` + +Please let me know if I can provide any further info. +-Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1905226 b/results/classifier/gemma3:12b/device/1905226 new file mode 100644 index 000000000..336f9841f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1905226 @@ -0,0 +1,16 @@ + +intel-hda: stream reset bits are broken + +From HD audio spec, section 3.3.35: + +"Stream Reset (SRST): Writing a 1 causes the corresponding stream to be reset. [...] After the stream hardware has completed sequencing into the reset state, it will report a 1 in this bit. Software must read a 1 from this bit to verify that the stream is in reset. Writing a 0 causes the corresponding stream to exit reset. When the stream hardware is ready to begin operation, it will report a 0 in this bit. Software must read a 0 from this bit before accessing any of the stream registers." + +So to reset a stream I set the bit, but it never reads back as 1 so the driver either times out or will hang forever waiting for it to become 1. I looked into why this happens and found that as of the latest version (8110fa1), in function intel_hda_set_st_ctl() of the https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c, + + if (st->ctl & 0x01) { + /* reset */ + dprint(d, 1, "st #%d: reset\n", reg->stream); + st->ctl = SD_STS_FIFO_READY << 24; + } + +This causes the bit to immediately become set to 0 even if I write a 1, and clearly does not meet the spec. I checked behaviour of real hardware and it works as expected, i.e. I see the bit will become 1 and 0 when I write to it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1905297 b/results/classifier/gemma3:12b/device/1905297 new file mode 100644 index 000000000..7d21a61fd --- /dev/null +++ b/results/classifier/gemma3:12b/device/1905297 @@ -0,0 +1,30 @@ + +Zynq7000 UART clock reset initialization + +Hello, + +we have come across a strange behavior in the Zynq7000 model of Qemu that seems to have been introduced between 5.0.0 and 5.1.0. + + +The reset values of the SLCR register, in particular those for UART_CLK_CTRL, are such that +the UARTs should find functional clocks. Up to 5.0.0 this was also the behavior that was +implemented in QEMU. + +Starting in 5.1.0, we found that - despite correct reset values [1] - the UARTs are non-functional +upon reset. Some investigation revealed that the cause for that is that the corresponding +clocks are not properly initialized. + +Between 5.0.0 and 5.1.0, there are three commits that touch the Zynq UART clocks [2]. The last of them [3] triggers the faulty behavior. + +Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We surmise that the +underlying device release issue runs much deeper, so it is only meant to identify the issue. + + + +[1] hw/misc/zynq_slcr.c + static void zynq_slcr_reset_init(Object *obj, ResetType type) + s->regs[R_UART_CLK_CTRL] = 0x00003F03; +[2] 38867cb7ec90..5b49a34c6800 +[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) + Author: Damien Hedde <email address hidden> + Date: Mon Apr 6 15:52:50 2020 +0200 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1905444 b/results/classifier/gemma3:12b/device/1905444 new file mode 100644 index 000000000..8dc62a199 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1905444 @@ -0,0 +1,47 @@ + +[OSS-Fuzz] Issue 27796 in oss-fuzz: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci: Stack-overflow in address_space_stl_internal + + affects qemu + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27796 + +=== Reproducer (build with --enable-sanitizers) === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-qtest-log none -qtest stdio +outl 0xcf8 0x80000803 +outw 0xcfc 0x5e46 +outl 0xcf8 0x80000810 +outl 0xcfc 0xff5a5e46 +write 0xff5a5020 0x6 0xffffffff0b70 +outl 0xcf8 0x80000893 +outb 0xcfc 0x93 +writel 0xff5a7000 0xff5a5020 +write 0xff5a700c 0x4 0x0c0c2e58 +write 0xff5a4040 0x4 0x00d26001 +write 0xff5a4044 0x4 0x0000030 +EOF + +=== Stack Trace === +==50473==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe3ec97e28 (pc 0x55e292eac159 bp 0x7ffe3ec98670 sp 0x7ffe3ec97e30 T0) +#0 0x55e292eac159 in __asan_memcpy (u-system-i386+0x2a0e159) +#1 0x55e2944bc04e in flatview_do_translate softmmu/physmem.c:513:12 +#2 0x55e2944dbe90 in flatview_translate softmmu/physmem.c:563:15 +#3 0x55e2944dbe90 in address_space_translate include/exec/memory.h:2362:12 +#4 0x55e2944dbe90 in address_space_stl_internal memory_ldst.c.inc:316:10 +#5 0x55e29393d2a0 in xhci_intr_update hw/usb/hcd-xhci.c:554:13 +#6 0x55e29393efb9 in xhci_runtime_write hw/usb/hcd-xhci.c:3032:9 +#7 0x55e294230428 in memory_region_write_accessor softmmu/memory.c:484:5 +#8 0x55e29422fe63 in access_with_adjusted_size softmmu/memory.c:545:18 +#9 0x55e29422f6fc in memory_region_dispatch_write softmmu/memory.c +#10 0x55e2944dc03c in address_space_stl_internal memory_ldst.c.inc:319:13 +#11 0x55e29393d2a0 in xhci_intr_update hw/usb/hcd-xhci.c:554:13 +#12 0x55e29393efb9 in xhci_runtime_write hw/usb/hcd-xhci.c:3032:9 +#13 0x55e294230428 in memory_region_write_accessor softmmu/memory.c:484:5 +#14 0x55e29422fe63 in access_with_adjusted_size softmmu/memory.c:545:18 +#15 0x55e29422f6fc in memory_region_dispatch_write softmmu/memory.c +#16 0x55e2944dc03c in address_space_stl_internal memory_ldst.c.inc:319:13 +#17 0x55e29393d2a0 in xhci_intr_update hw/usb/hcd-xhci.c:554:13 +#18 0x55e29393efb9 in xhci_runtime_write hw/usb/hcd-xhci.c:3032:9 diff --git a/results/classifier/gemma3:12b/device/1905521 b/results/classifier/gemma3:12b/device/1905521 new file mode 100644 index 000000000..69f492d9a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1905521 @@ -0,0 +1,44 @@ + +assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed + +Hello, + +I found an assertion failure in hw/scsi/lsi53c895a.c:624 + +This was found in latest version 5.2.0. + + +my reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + + + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device lsi53c895a -trace lsi\* + +Backtrace is as follows: +#0 0x00007f845c6eff47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f845c6f18b1 in __GI_abort () at abort.c:79 +#2 0x00007f845c6e142a in __assert_fail_base (fmt=0x7f845c868a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a1034486a0 "s->current", file=file@entry=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=line@entry=624, function=function@entry=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:92 +#3 0x00007f845c6e14a2 in __GI___assert_fail (assertion=0x55a1034486a0 "s->current", file=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=624, function=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:101 +#4 0x000055a102049c65 in lsi_do_dma (s=0x62600000c100, out=1) at ../hw/scsi/lsi53c895a.c:624 +#5 0x000055a102051573 in lsi_execute_script (s=0x62600000c100) at ../hw/scsi/lsi53c895a.c:1250 +#6 0x000055a10205b05d in lsi_reg_writeb (s=0x62600000c100, offset=47, val=178 '\262') at ../hw/scsi/lsi53c895a.c:1984 +#7 0x000055a10205fef8 in lsi_io_write (opaque=0x62600000c100, addr=47, val=178, size=1) at ../hw/scsi/lsi53c895a.c:2146 +#8 0x000055a102d1b791 in memory_region_write_accessor (mr=0x62600000cbe0, addr=47, value=0x7f8349dfe2f8, size=1, shift=0, mask=255, attrs=...) at ../softmmu/memory.c:484 +#9 0x000055a102d1bba8 in access_with_adjusted_size (addr=47, value=0x7f8349dfe2f8, size=1, access_size_min=1, access_size_max=1, access_fn=0x55a102d1b4de <memory_region_write_accessor>, mr=0x62600000cbe0, attrs=...) at ../softmmu/memory.c:545 +#10 0x000055a102d261ef in memory_region_dispatch_write (mr=0x62600000cbe0, addr=47, data=178, op=MO_8, attrs=...) at ../softmmu/memory.c:1494 +#11 0x000055a102b57c3c in flatview_write_continue (fv=0x6060000ea920, addr=49199, attrs=..., ptr=0x7f8449efb000, len=1, addr1=47, l=1, mr=0x62600000cbe0) at ../softmmu/physmem.c:2767 +#12 0x000055a102b57f07 in flatview_write (fv=0x6060000ea920, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2807 +#13 0x000055a102b587cb in address_space_write (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2899 +#14 0x000055a102b58878 in address_space_rw (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1, is_write=true) at ../softmmu/physmem.c:2909 +#15 0x000055a102ad4d50 in kvm_handle_io (port=49199, attrs=..., data=0x7f8449efb000, direction=1, size=1, count=1) at ../accel/kvm/kvm-all.c:2283 +#16 0x000055a102ad6a0f in kvm_cpu_exec (cpu=0x62e000000400) at ../accel/kvm/kvm-all.c:2529 +#17 0x000055a102c26fbb in kvm_vcpu_thread_fn (arg=0x62e000000400) at ../accel/kvm/kvm-cpus.c:49 +#18 0x000055a1032c08f8 in qemu_thread_start (args=0x603000082780) at ../util/qemu-thread-posix.c:521 +#19 0x00007f845caa96db in start_thread (arg=0x7f8349dff700) at pthread_create.c:463 +#20 0x00007f845c7d2a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +The poc is attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1905651 b/results/classifier/gemma3:12b/device/1905651 new file mode 100644 index 000000000..c26ca828f --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1906295 b/results/classifier/gemma3:12b/device/1906295 new file mode 100644 index 000000000..fea03b49e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1906295 @@ -0,0 +1,12 @@ + +Implementation of exclusive monitor in ARM + +Hi + +I refer to the implementation of exclusive monitor in ARM32. For instruction like STREX Rx,Ry,[Rz], we need to check whether the address [Rz] is in exclusive state. If not, we set the value Rx as 1 without doing the store operation. However, I noticed that QEMU will not check whether the address that Rz points to is a legal address or not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU will set Rx as 1 and continue to execute the following instructions. + +However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. +Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1906463 b/results/classifier/gemma3:12b/device/1906463 new file mode 100644 index 000000000..f0b3696a7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1906463 @@ -0,0 +1,19 @@ + +"-device help" does not report all devices + +-device help doesn't report all devices. +E.g., devices that are instantiated by a board don't get printed in part because they don't exist when "-device help" is processed. As an experiment I deferred processing of "-device help" as long as possible and some devices were still not printed, so there's more going on here. + +QEMU commit hash: 944fdc5e27a5b5adbb765891e8e70e88ba9a00ec + +Repro: +$ configure --target-list=arm-softmmu +$ make +$ ./qemu-system-arm -device help | grep npcm7xx +<empty> + +I'd expect to see things like npcm7xx-rng in the output. + +I can imagine enumerating board-provided devices is a challenge. +Still, it'd be really nice if "-device help" printed them, and having +"-device $driver,help" work as well. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1906693 b/results/classifier/gemma3:12b/device/1906693 new file mode 100644 index 000000000..3c7c4a03b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1906693 @@ -0,0 +1,173 @@ + +Assertion Failure in bdrv_co_write_req_prepare through megasas + + affects qemu + subscribe <email address hidden> + subscribe <email address hidden> + subscribe <email address hidden> + subscribe <email address hidden> + +=== Stack Trace === +qemu-fuzz-i386: block/io.c:1835: int bdrv_co_write_req_prepare(BdrvChild *, int64_t, uint64_t, BdrvTrackedRequest *, int): Assertion `child->perm & BLK_PERM_WRITE' failed. +==1505128== ERROR: libFuzzer: deadly signal + #0 0x55a083b92cee in __sanitizer_print_stack_trace (qemu-fuzz-i386+0x793cee) + #1 0x55a083b6c1d1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0x76d1d1) + #2 0x55a083b4f0d6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (qemu-fuzz-i386+0x7500d6) + #3 0x55a083b4f19b in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0x75019b) + #4 0x7f8d24ed6a8f (/lib64/libpthread.so.0+0x14a8f) + #5 0x7f8d24d079e4 in raise (/lib64/libc.so.6+0x3c9e4) + #6 0x7f8d24cf0894 in abort (/lib64/libc.so.6+0x25894) + #7 0x7f8d24cf0768 in __assert_fail_base.cold (/lib64/libc.so.6+0x25768) + #8 0x7f8d24cffe75 in __assert_fail (/lib64/libc.so.6+0x34e75) + #9 0x55a08423763f in bdrv_co_write_req_prepare block/io.c:1835:13 + #10 0x55a0842343a8 in bdrv_aligned_pwritev block/io.c:1915:11 + #11 0x55a084233765 in bdrv_co_pwritev_part block/io.c:2104:11 + #12 0x55a084260d1a in blk_do_pwritev_part block/block-backend.c:1260:11 + #13 0x55a08426163e in blk_aio_write_entry block/block-backend.c:1476:17 + #14 0x55a0843b0d23 in coroutine_trampoline util/coroutine-ucontext.c:173:9 + #15 0x7f8d24d1d22f (/lib64/libc.so.6+0x5222f) + +=== Reproducer=== +cat << EOF | ./qemu-system-i386 -M q35 \ +-device megasas-gen2 -device scsi-cd,drive=null0 \ +-blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +-monitor none -serial none -display none \ +-machine accel=qtest -m 64 -qtest stdio +outl 0xcf8 0x80001804 +outl 0xcfc 0xffffff +outl 0xcf8 0x8000181b +outl 0xcfc 0x7052005 +write 0x5cc0 0x1 0x03 +write 0x5cc7 0x1 0x40 +write 0x5ce0 0x1 0x0a +write 0x5cf3 0x1 0x01 +write 0x5cf7 0x1 0x40 +write 0x5cf8 0x1 0x0a +write 0x5cff 0x1 0x05 +write 0x5d03 0x1 0x5b +write 0x5d06 0x1 0x4f +write 0x5d0b 0x1 0x01 +write 0x5d0f 0x1 0x40 +write 0x5d10 0x1 0x0a +write 0x5d17 0x1 0x05 +write 0x5d1b 0x1 0x5b +write 0x5d1e 0x1 0x4f +write 0x5d23 0x1 0x01 +write 0x5d27 0x1 0x40 +write 0x5d28 0x1 0x0a +write 0x5d2f 0x1 0x05 +write 0x5d33 0x1 0x5b +write 0x5d36 0x1 0x4f +write 0x5d3b 0x1 0x01 +write 0x5d3f 0x1 0x40 +write 0x5d40 0x1 0x0a +write 0x5d47 0x1 0x05 +write 0x5d4b 0x1 0x5b +write 0x5d4e 0x1 0x4f +write 0x5d53 0x1 0x01 +write 0x5d57 0x1 0x40 +write 0x5d58 0x1 0x0a +write 0x5d5f 0x1 0x05 +write 0x5d63 0x1 0x5b +write 0x5d66 0x1 0x4f +write 0x5d6b 0x1 0x01 +write 0x5d6f 0x1 0x40 +write 0x5d70 0x1 0x0a +write 0x5d77 0x1 0x05 +write 0x5d7b 0x1 0x5b +write 0x5d7e 0x1 0x4f +write 0x5d83 0x1 0x01 +write 0x5d87 0x1 0x40 +write 0x5d88 0x1 0x0a +write 0x5d8f 0x1 0x05 +write 0x5d93 0x1 0x5b +write 0x5d96 0x1 0x4f +write 0x5d9b 0x1 0x01 +write 0x5d9f 0x1 0x40 +write 0x5da0 0x1 0x0a +write 0x5da7 0x1 0x05 +write 0x5dab 0x1 0x5b +write 0x5dae 0x1 0x4f +write 0x5db3 0x1 0x01 +write 0x5db7 0x1 0x40 +write 0x5db8 0x1 0x0a +write 0x5dbf 0x1 0x05 +write 0x5dc3 0x1 0x5b +write 0x5dc6 0x1 0x4f +write 0x5dcb 0x1 0x01 +write 0x5dcf 0x1 0x40 +write 0x5dd0 0x1 0x0a +write 0x5dd7 0x1 0x05 +write 0x5ddb 0x1 0x5b +write 0x5dde 0x1 0x4f +write 0x5de3 0x1 0x01 +write 0x5de7 0x1 0x40 +write 0x5de8 0x1 0x0a +write 0x5def 0x1 0x05 +write 0x5df3 0x1 0x5b +write 0x5df6 0x1 0x4f +write 0x5dfb 0x1 0x01 +write 0x5dff 0x1 0x40 +write 0x5e00 0x1 0x0a +write 0x5e07 0x1 0x05 +write 0x5e0b 0x1 0x5b +write 0x5e0e 0x1 0x4f +write 0x5e13 0x1 0x01 +write 0x5e17 0x1 0x40 +write 0x5e18 0x1 0x0a +write 0x5e1f 0x1 0x05 +write 0x5e23 0x1 0x5b +write 0x5e26 0x1 0x4f +write 0x5e2b 0x1 0x01 +write 0x5e2f 0x1 0x40 +write 0x5e30 0x1 0x0a +write 0x5e37 0x1 0x05 +write 0x5e3b 0x1 0x5b +write 0x5e3e 0x1 0x4f +write 0x5e43 0x1 0x01 +write 0x5e47 0x1 0x40 +write 0x5e48 0x1 0x0a +write 0x5e4f 0x1 0x05 +write 0x5e53 0x1 0x5b +write 0x5e56 0x1 0x4f +write 0x5e5b 0x1 0x01 +write 0x5e5f 0x1 0x40 +write 0x5e60 0x1 0x0a +write 0x5e67 0x1 0x05 +write 0x5e6b 0x1 0x5b +write 0x5e6e 0x1 0x4f +write 0x5e73 0x1 0x01 +write 0x5e77 0x1 0x40 +write 0x5e78 0x1 0x0a +write 0x5e7f 0x1 0x05 +write 0x5e83 0x1 0x5b +write 0x5e86 0x1 0x4f +write 0x5e8b 0x1 0x01 +write 0x5e8f 0x1 0x40 +write 0x5e90 0x1 0x0a +write 0x5e97 0x1 0x05 +write 0x5e9b 0x1 0x5b +write 0x5e9e 0x1 0x4f +write 0x5ea3 0x1 0x01 +write 0x5ea7 0x1 0x40 +write 0x5ea8 0x1 0x0a +write 0x5eaf 0x1 0x05 +write 0x5eb3 0x1 0x5b +write 0x5eb6 0x1 0x4f +write 0x5ebb 0x1 0x01 +write 0x5ebf 0x1 0x40 +write 0x5ec0 0x1 0x0a +write 0x5ec7 0x1 0x05 +write 0x5ecb 0x1 0x5b +write 0x5ece 0x1 0x4f +write 0x5ed3 0x1 0x01 +write 0x5ed7 0x1 0x40 +write 0x5ed8 0x1 0x0a +write 0x5edf 0x1 0x05 +write 0x5ee3 0x1 0x5b +write 0x5ee6 0x1 0x4f +write 0x5eeb 0x1 0x01 +write 0x5eef 0x1 0x40 +writeq 0x50000000000003b 0x15cd405b60101c8 +EOF + diff --git a/results/classifier/gemma3:12b/device/1906694 b/results/classifier/gemma3:12b/device/1906694 new file mode 100644 index 000000000..d263adb57 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1906694 @@ -0,0 +1,171 @@ + +Assertion Failure in bdrv_co_write_req_prepare through megasas + + affects qemu + subscribe <email address hidden> + subscribe <email address hidden> + +=== Stack Trace === +qemu-fuzz-i386: block/io.c:1835: int bdrv_co_write_req_prepare(BdrvChild *, int64_t, uint64_t, BdrvTrackedRequest *, int): Assertion `child->perm & BLK_PERM_WRITE' failed. +==1505128== ERROR: libFuzzer: deadly signal + #0 0x55a083b92cee in __sanitizer_print_stack_trace (qemu-fuzz-i386+0x793cee) + #1 0x55a083b6c1d1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0x76d1d1) + #2 0x55a083b4f0d6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (qemu-fuzz-i386+0x7500d6) + #3 0x55a083b4f19b in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0x75019b) + #4 0x7f8d24ed6a8f (/lib64/libpthread.so.0+0x14a8f) + #5 0x7f8d24d079e4 in raise (/lib64/libc.so.6+0x3c9e4) + #6 0x7f8d24cf0894 in abort (/lib64/libc.so.6+0x25894) + #7 0x7f8d24cf0768 in __assert_fail_base.cold (/lib64/libc.so.6+0x25768) + #8 0x7f8d24cffe75 in __assert_fail (/lib64/libc.so.6+0x34e75) + #9 0x55a08423763f in bdrv_co_write_req_prepare block/io.c:1835:13 + #10 0x55a0842343a8 in bdrv_aligned_pwritev block/io.c:1915:11 + #11 0x55a084233765 in bdrv_co_pwritev_part block/io.c:2104:11 + #12 0x55a084260d1a in blk_do_pwritev_part block/block-backend.c:1260:11 + #13 0x55a08426163e in blk_aio_write_entry block/block-backend.c:1476:17 + #14 0x55a0843b0d23 in coroutine_trampoline util/coroutine-ucontext.c:173:9 + #15 0x7f8d24d1d22f (/lib64/libc.so.6+0x5222f) + +=== Reproducer=== +cat << EOF | ./qemu-system-i386 -M q35 \ +-device megasas-gen2 -device scsi-cd,drive=null0 \ +-blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +-monitor none -serial none -display none \ +-machine accel=qtest -m 64 -qtest stdio +outl 0xcf8 0x80001804 +outl 0xcfc 0xffffff +outl 0xcf8 0x8000181b +outl 0xcfc 0x7052005 +write 0x5cc0 0x1 0x03 +write 0x5cc7 0x1 0x40 +write 0x5ce0 0x1 0x0a +write 0x5cf3 0x1 0x01 +write 0x5cf7 0x1 0x40 +write 0x5cf8 0x1 0x0a +write 0x5cff 0x1 0x05 +write 0x5d03 0x1 0x5b +write 0x5d06 0x1 0x4f +write 0x5d0b 0x1 0x01 +write 0x5d0f 0x1 0x40 +write 0x5d10 0x1 0x0a +write 0x5d17 0x1 0x05 +write 0x5d1b 0x1 0x5b +write 0x5d1e 0x1 0x4f +write 0x5d23 0x1 0x01 +write 0x5d27 0x1 0x40 +write 0x5d28 0x1 0x0a +write 0x5d2f 0x1 0x05 +write 0x5d33 0x1 0x5b +write 0x5d36 0x1 0x4f +write 0x5d3b 0x1 0x01 +write 0x5d3f 0x1 0x40 +write 0x5d40 0x1 0x0a +write 0x5d47 0x1 0x05 +write 0x5d4b 0x1 0x5b +write 0x5d4e 0x1 0x4f +write 0x5d53 0x1 0x01 +write 0x5d57 0x1 0x40 +write 0x5d58 0x1 0x0a +write 0x5d5f 0x1 0x05 +write 0x5d63 0x1 0x5b +write 0x5d66 0x1 0x4f +write 0x5d6b 0x1 0x01 +write 0x5d6f 0x1 0x40 +write 0x5d70 0x1 0x0a +write 0x5d77 0x1 0x05 +write 0x5d7b 0x1 0x5b +write 0x5d7e 0x1 0x4f +write 0x5d83 0x1 0x01 +write 0x5d87 0x1 0x40 +write 0x5d88 0x1 0x0a +write 0x5d8f 0x1 0x05 +write 0x5d93 0x1 0x5b +write 0x5d96 0x1 0x4f +write 0x5d9b 0x1 0x01 +write 0x5d9f 0x1 0x40 +write 0x5da0 0x1 0x0a +write 0x5da7 0x1 0x05 +write 0x5dab 0x1 0x5b +write 0x5dae 0x1 0x4f +write 0x5db3 0x1 0x01 +write 0x5db7 0x1 0x40 +write 0x5db8 0x1 0x0a +write 0x5dbf 0x1 0x05 +write 0x5dc3 0x1 0x5b +write 0x5dc6 0x1 0x4f +write 0x5dcb 0x1 0x01 +write 0x5dcf 0x1 0x40 +write 0x5dd0 0x1 0x0a +write 0x5dd7 0x1 0x05 +write 0x5ddb 0x1 0x5b +write 0x5dde 0x1 0x4f +write 0x5de3 0x1 0x01 +write 0x5de7 0x1 0x40 +write 0x5de8 0x1 0x0a +write 0x5def 0x1 0x05 +write 0x5df3 0x1 0x5b +write 0x5df6 0x1 0x4f +write 0x5dfb 0x1 0x01 +write 0x5dff 0x1 0x40 +write 0x5e00 0x1 0x0a +write 0x5e07 0x1 0x05 +write 0x5e0b 0x1 0x5b +write 0x5e0e 0x1 0x4f +write 0x5e13 0x1 0x01 +write 0x5e17 0x1 0x40 +write 0x5e18 0x1 0x0a +write 0x5e1f 0x1 0x05 +write 0x5e23 0x1 0x5b +write 0x5e26 0x1 0x4f +write 0x5e2b 0x1 0x01 +write 0x5e2f 0x1 0x40 +write 0x5e30 0x1 0x0a +write 0x5e37 0x1 0x05 +write 0x5e3b 0x1 0x5b +write 0x5e3e 0x1 0x4f +write 0x5e43 0x1 0x01 +write 0x5e47 0x1 0x40 +write 0x5e48 0x1 0x0a +write 0x5e4f 0x1 0x05 +write 0x5e53 0x1 0x5b +write 0x5e56 0x1 0x4f +write 0x5e5b 0x1 0x01 +write 0x5e5f 0x1 0x40 +write 0x5e60 0x1 0x0a +write 0x5e67 0x1 0x05 +write 0x5e6b 0x1 0x5b +write 0x5e6e 0x1 0x4f +write 0x5e73 0x1 0x01 +write 0x5e77 0x1 0x40 +write 0x5e78 0x1 0x0a +write 0x5e7f 0x1 0x05 +write 0x5e83 0x1 0x5b +write 0x5e86 0x1 0x4f +write 0x5e8b 0x1 0x01 +write 0x5e8f 0x1 0x40 +write 0x5e90 0x1 0x0a +write 0x5e97 0x1 0x05 +write 0x5e9b 0x1 0x5b +write 0x5e9e 0x1 0x4f +write 0x5ea3 0x1 0x01 +write 0x5ea7 0x1 0x40 +write 0x5ea8 0x1 0x0a +write 0x5eaf 0x1 0x05 +write 0x5eb3 0x1 0x5b +write 0x5eb6 0x1 0x4f +write 0x5ebb 0x1 0x01 +write 0x5ebf 0x1 0x40 +write 0x5ec0 0x1 0x0a +write 0x5ec7 0x1 0x05 +write 0x5ecb 0x1 0x5b +write 0x5ece 0x1 0x4f +write 0x5ed3 0x1 0x01 +write 0x5ed7 0x1 0x40 +write 0x5ed8 0x1 0x0a +write 0x5edf 0x1 0x05 +write 0x5ee3 0x1 0x5b +write 0x5ee6 0x1 0x4f +write 0x5eeb 0x1 0x01 +write 0x5eef 0x1 0x40 +writeq 0x50000000000003b 0x15cd405b60101c8 +EOF + diff --git a/results/classifier/gemma3:12b/device/1907497 b/results/classifier/gemma3:12b/device/1907497 new file mode 100644 index 000000000..425cf1085 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1907497 @@ -0,0 +1,59 @@ + +[OSS-Fuzz] Issue 28435 qemu:qemu-fuzz-i386-target-generic-fuzz-intel-hda: Stack-overflow in ldl_le_dma + + affects qemu + +=== Reproducer (build with --enable-sanitizers) === + +cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +-device intel-hda,id=hda0 -device hda-output,bus=hda0.0 \ +-device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 \ +-qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0xffff +write 0x0 0x1 0x12 +write 0x2 0x1 0x2f +outl 0xcf8 0x80000811 +outl 0xcfc 0x5a6a4406 +write 0x6a44005a 0x1 0x11 +write 0x6a44005c 0x1 0x3f +write 0x6a442050 0x4 0x0000446a +write 0x6a44204a 0x1 0xf3 +write 0x6a44204c 0x1 0xff +writeq 0x6a44005a 0x17b3f0011 +write 0x6a442050 0x4 0x0000446a +write 0x6a44204a 0x1 0xf3 +write 0x6a44204c 0x1 0xff +EOF + +=== Stack Trace === +==411958==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcaeb8bc88 (pc 0x55c7c9dc1159 bp 0x7ffcaeb8c4d0 sp 0x7ffcaeb8bc90 T0) + #0 0x55c7c9dc1159 in __asan_memcpy (u-system-i386+0x2a13159) + #1 0x55c7cb2a457e in flatview_do_translate softmmu/physmem.c:513:12 + #2 0x55c7cb2bdab0 in flatview_translate softmmu/physmem.c:563:15 + #3 0x55c7cb2bdab0 in flatview_read softmmu/physmem.c:2861:10 + #4 0x55c7cb2bdab0 in address_space_read_full softmmu/physmem.c:2875:18 + #5 0x55c7caaec937 in dma_memory_rw_relaxed include/sysemu/dma.h:87:18 + #6 0x55c7caaec937 in dma_memory_rw include/sysemu/dma.h:110:12 + #7 0x55c7caaec937 in dma_memory_read include/sysemu/dma.h:116:12 + #8 0x55c7caaec937 in ldl_le_dma include/sysemu/dma.h:179:1 + #9 0x55c7caaec937 in ldl_le_pci_dma include/hw/pci/pci.h:816:1 + #10 0x55c7caaec937 in intel_hda_corb_run hw/audio/intel-hda.c:338:16 + #11 0x55c7cb2e7198 in memory_region_write_accessor softmmu/memory.c:491:5 + #12 0x55c7cb2e6bd3 in access_with_adjusted_size softmmu/memory.c:552:18 + #13 0x55c7cb2e646c in memory_region_dispatch_write softmmu/memory.c + #14 0x55c7cb2c8445 in flatview_write_continue softmmu/physmem.c:2759:23 + #15 0x55c7cb2bdfb8 in flatview_write softmmu/physmem.c:2799:14 + #16 0x55c7cb2bdfb8 in address_space_write softmmu/physmem.c:2891:18 + #17 0x55c7caae2c54 in dma_memory_rw_relaxed include/sysemu/dma.h:87:18 + #18 0x55c7caae2c54 in dma_memory_rw include/sysemu/dma.h:110:12 + #19 0x55c7caae2c54 in dma_memory_write include/sysemu/dma.h:122:12 + #20 0x55c7caae2c54 in stl_le_dma include/sysemu/dma.h:179:1 + #21 0x55c7caae2c54 in stl_le_pci_dma include/hw/pci/pci.h:816:1 + #22 0x55c7caae2c54 in intel_hda_response hw/audio/intel-hda.c:370:5 + #23 0x55c7caaeca00 in intel_hda_corb_run hw/audio/intel-hda.c:342:9 + #24 0x55c7cb2e7198 in memory_region_write_accessor softmmu/memory.c:491:5 +... + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28435 + diff --git a/results/classifier/gemma3:12b/device/1907909 b/results/classifier/gemma3:12b/device/1907909 new file mode 100644 index 000000000..7b809b9c7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1907909 @@ -0,0 +1,56 @@ + +assertion failure in am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/esp.c:402: void esp_do_dma(ESPState *): Assertion `s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen' failed. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fdd25dc4700 (LWP 28983))] +gdb-peda$ bt +#0 0x00007fdd3f8b5f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fdd3f8b78b1 in __GI_abort () at abort.c:79 +#2 0x00007fdd3f8a742a in __assert_fail_base (fmt=0x7fdd3fa2ea38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=file@entry=0x55b3e11a4f73 "../hw/scsi/esp.c", line=line@entry=0x192, function=function@entry=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:92 +#3 0x00007fdd3f8a74a2 in __GI___assert_fail (assertion=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=0x55b3e11a4f73 "../hw/scsi/esp.c", line=0x192, function=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:101 +#4 0x000055b3e0941441 in esp_do_dma (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:401 +#5 0x000055b3e0944261 in handle_ti (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:549 +#6 0x000055b3e093fdf9 in esp_dma_enable (s=0x55b3e49d1c88, irq=<optimized out>, level=<optimized out>) + at ../hw/scsi/esp.c:79 +#7 0x000055b3e0897930 in esp_pci_dma_write (pci=<optimized out>, saddr=<optimized out>, val=<optimized +out>) at ../hw/scsi/esp-pci.c:83 +#8 0x000055b3e0897930 in esp_pci_io_write (opaque=<optimized out>, addr=<optimized out>, val=0xcf, size=0x4) at ../hw/scsi/esp-pci.c:209 +#9 0x000055b3e0e8f798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#10 0x000055b3e0e8f58e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#11 0x000055b3e0e8f58e in memory_region_dispatch_write (mr=0x55b3e49d1b70, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#12 0x000055b3e0e21541 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=0xffffffcf, attrs=..., result=0x0) at ../memory_ldst.c.inc:382 +#13 0x00007fdcd84a4a7f in code_gen_buffer () +#14 0x000055b3e0e57da0 in cpu_tb_exec (cpu=0x55b3e3c33650, itb=<optimized out>) + at ../accel/tcg/cpu-exec.c:178 +#15 0x000055b3e0e589eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized +out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#16 0x000055b3e0e589eb in cpu_exec (cpu=0x55b3e3c33650) at ../accel/tcg/cpu-exec.c:771 +#17 0x000055b3e0e87b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#18 0x000055b3e0e87b9f in tcg_cpu_thread_fn (arg=0x55b3e3c33650) at ../accel/tcg/tcg-cpus.c:427 +#19 0x000055b3e115f775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#20 0x00007fdd3fc6f6db in start_thread (arg=0x7fdd25dc4700) at pthread_create.c:463 +#21 0x00007fdd3f998a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +To reproduce the assertion failure, please run the QEMU with the following command line. + + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1907926 b/results/classifier/gemma3:12b/device/1907926 new file mode 100644 index 000000000..219c72daf --- /dev/null +++ b/results/classifier/gemma3:12b/device/1907926 @@ -0,0 +1,6 @@ + +Implement TPM2 configuration for emulators that provide TCP interface + +swtpm provides several interfaces for its emulated device: unix socket (can be used by qemu), chardev. swtpm also provides TCP interface for the device which is very convenient for testing as it does not require root permissions. + +It would be very useful to have QEMU to work with TPM devices emulated via TCP. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1907938 b/results/classifier/gemma3:12b/device/1907938 new file mode 100644 index 000000000..6afbe4454 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1907938 @@ -0,0 +1,73 @@ + +[OSS-Fuzz] Issue 28524 virtio-blk: ASSERT: !s->dataplane_started + + affects qemu + +=== Reproducer === + +cat << EOF |./qemu-system-i386 -display none -m 512M -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw -qtest stdio +outl 0xcf8 0x8000181f +outl 0xcfc 0xa044d79 +outl 0xcf8 0x80001802 +outl 0xcf8 0x80001804 +outl 0xcfc 0xb9045dff +outl 0xcf8 0x8000180e +outl 0xcfc 0xfb9465a +outl 0xf85 0x9e1ea5c2 +write 0x9f002 0x1 0x04 +write 0x9f004 0x1 0x04 +write 0x9e040 0x1 0x04 +write 0x9e043 0x1 0x01 +write 0x9e048 0x1 0x10 +write 0x9e04c 0x1 0x01 +write 0x9e04e 0x1 0x6e +write 0x1000004 0x1 0x01 +write 0x9e6e3 0x1 0x01 +write 0x9e6eb 0x1 0x04 +write 0x9e6ec 0x1 0x6e +write 0x9f006 0x1 0x04 +write 0x9f008 0x1 0x04 +write 0x9f00a 0x1 0x04 +outl 0xf8f 0xc +EOF + +=== Stack Trace === + +qemu-fuzz-i386: ../hw/block/virtio-blk.c:917: void virtio_blk_reset(VirtIODevice *): Assertion `!s->dataplane_started' failed. +==702068== ERROR: libFuzzer: deadly signal +#0 0x55bd6fc9f311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311) +#1 0x55bd6fbe83d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8) +#2 0x55bd6fbce413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413) +#3 0x7ff5241b813f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f) +#4 0x7ff523feddb0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 +#5 0x7ff523feddb0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7ff523fd7536 in abort stdlib/abort.c:79:7 +#7 0x7ff523fd740e in __assert_fail_base assert/assert.c:92:3 +#8 0x7ff523fe65b1 in __assert_fail assert/assert.c:101:3 +#9 0x55bd7116c435 in virtio_blk_reset hw/block/virtio-blk.c:917:5 +#10 0x55bd710c94a2 in virtio_reset hw/virtio/virtio.c:2001:9 +#11 0x55bd6ff0e0a5 in virtio_pci_reset hw/virtio/virtio-pci.c:1886:5 +#12 0x55bd6ff10686 in virtio_ioport_write hw/virtio/virtio-pci.c:339:13 +#13 0x55bd6ff10686 in virtio_pci_config_write hw/virtio/virtio-pci.c:456:9 +#14 0x55bd713fd025 in memory_region_write_accessor softmmu/memory.c:491:5 +#15 0x55bd713fca93 in access_with_adjusted_size softmmu/memory.c:552:18 +#16 0x55bd713fc2f0 in memory_region_dispatch_write softmmu/memory.c +#17 0x55bd70e4bf36 in flatview_write_continue softmmu/physmem.c:2759:23 +#18 0x55bd70e41bbb in flatview_write softmmu/physmem.c:2799:14 +#19 0x55bd70e41bbb in address_space_write softmmu/physmem.c:2891:18 +#20 0x55bd71153462 in cpu_outl softmmu/ioport.c:80:5 +#21 0x55bd712d586e in qtest_process_command softmmu/qtest.c:483:13 +#22 0x55bd712d35bf in qtest_process_inbuf softmmu/qtest.c:797:9 +#23 0x55bd712d3315 in qtest_server_inproc_recv softmmu/qtest.c:904:9 +#24 0x55bd71910df8 in qtest_sendf tests/qtest/libqtest.c:438:5 +#25 0x55bd71911fae in qtest_out tests/qtest/libqtest.c:952:5 +#26 0x55bd71911fae in qtest_outl tests/qtest/libqtest.c:968:5 +#27 0x55bd6fcd1aa2 in op_out tests/qtest/fuzz/generic_fuzz.c:395:13 +#28 0x55bd6fcd04e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17 +#29 0x55bd6fcc9723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28524 + diff --git a/results/classifier/gemma3:12b/device/1908062 b/results/classifier/gemma3:12b/device/1908062 new file mode 100644 index 000000000..fa6b01665 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1908062 @@ -0,0 +1,73 @@ + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again + +When I was fuzzing virtio-vga device of the latest QEMU (1758428, Dec 12, built with --enable-sanitizers --enable-fuzzing), an assertion failed in include/exec/memory_ldst_cached.h.inc. + +--[ Reproducer + +cat << EOF | ./build/i386-softmmu/qemu-system-i386 -machine accel=qtest \ +-machine q35 -display none -nodefaults -device virtio-vga -qtest stdio +outl 0xcf8 0x8000081c +outb 0xcfc 0xc3 +outl 0xcf8 0x80000804 +outb 0xcfc 0x06 +write 0xc300001024 0x2 0x0040 +write 0xc300001028 0x1 0x5a +write 0xc30000101c 0x1 0x01 +writel 0xc30000100c 0x20000000 +write 0xc300001016 0x3 0x80a080 +write 0xc300003002 0x1 0x80 +write 0x5c 0x1 0x10 +EOF + +--[ Output + +==35337==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 1607946348.442865] OPENED +[R +0.059305] outl 0xcf8 0x8000081c +OK +[S +0.059326] OK +[R +0.059338] outb 0xcfc 0xc3 +OK +[S +0.059355] OK +[R +0.059363] outl 0xcf8 0x80000804 +OK +[S +0.059369] OK +[R +0.059381] outb 0xcfc 0x06 +OK +[S +0.061094] OK +[R +0.061107] write 0xc300001024 0x2 0x0040 +OK +[S +0.061120] OK +[R +0.061127] write 0xc300001028 0x1 0x5a +OK +[S +0.061135] OK +[R +0.061142] write 0xc30000101c 0x1 0x01 +OK +[S +0.061158] OK +[R +0.061167] writel 0xc30000100c 0x20000000 +OK +[S +0.061212] OK +[R +0.061222] write 0xc300001016 0x3 0x80a080 +OK +[S +0.061231] OK +[R +0.061238] write 0xc300003002 0x1 0x80 +OK +[S +0.061247] OK +[R +0.061253] write 0x5c 0x1 0x10 +OK +[S +0.061403] OK +qemu-system-i386: /home/qiuhao/hack/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + +--[ Environment + +Ubuntu 20.04.1 5.4.0-58-generic x86_64 +clang: 10.0.0-4ubuntu1 +glibc: 2.31-0ubuntu9.1 +libglib2.0-dev: 2.64.3-1~ubuntu20.04.1 + +--[ Note + +Alexander Bulekov found the same assertion failure on 2020-08-04, https://bugs.launchpad.net/qemu/+bug/1890333, and it had been fixed in commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1. + +Fam Zheng found the same assertion failure on 2018-09-29, https://bugs.launchpad.net/qemu/+bug/1795148, and it had been fixed in commit db812c4073c77c8a64db8d6663b3416a587c7b4a. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1908450 b/results/classifier/gemma3:12b/device/1908450 new file mode 100644 index 000000000..6ab43f86c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1908450 @@ -0,0 +1,47 @@ + +ide/core.c ATA Major Version reporting incorrect + +@@ -165,7 +165,7 @@ static void ide_identify(IDEState *s) + put_le16(p + 76, (1 << 8)); + } + + put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ +- put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ ++ put_le16(p + 80, ((1 << 6) | (1 << 5) (1 << 4) (1 << 3)); /* ata3 -> ata6 supported */ + put_le16(p + 81, 0x16); /* conforms to ata5 */ + /* 14=NOP supported, 5=WCACHE supported, 0=SMART supported */ + put_le16(p + 82, (1 << 14) | (1 << 5) | 1); + + +This field Major Version Number field is presently reporting support for ATA-4 through ATA-7. +Bitfield[80] is defined in the ATA-6 specification below. + +0xF0 = (1<<7) | (1<<6) | (1 << 5) | (1 << 4) // 4-7 - current settings +0x78 = (1<<6) | (1<<5) | (1 << 4) | (1 << 3) // 3-6 - new settings + +Either the comment is wrong, or the field is wrong. If the field is wrong it can cause errors in drivers that check support vs conformity. This will not break most guests, since the conformity field is set to ATA-5. + +I'm not sure whether this component supports ATA-7, but since it's commented as if it supports up through 6, correcting the field assignment seems more correct. + +ATA/ATAPI-6 Specification +https://web.archive.org/web/20200124094822/https://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf + +Page 116 +80 - M Major version number +0000h or FFFFh = device does not report version +F 15 Reserved +F 14 Reserved for ATA/ATAPI-14 +F 13 Reserved for ATA/ATAPI-13 +F 12 Reserved for ATA/ATAPI-12 +F 11 Reserved for ATA/ATAPI-11 +F 10 Reserved for ATA/ATAPI-10 +F 9 Reserved for ATA/ATAPI-9 +F 8 Reserved for ATA/ATAPI-8 +F 7 Reserved for ATA/ATAPI-7 +F 6 1 = supports ATA/ATAPI-6 +F 5 1 = supports ATA/ATAPI-5 +F 4 1 = supports ATA/ATAPI-4 +F 3 1 = supports ATA-3 +X 2 Obsolete +X 1 Obsolete +F 0 Reserved \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1908513 b/results/classifier/gemma3:12b/device/1908513 new file mode 100644 index 000000000..2b83c305a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1908513 @@ -0,0 +1,56 @@ + +assertion failure in mptsas1068 emulator + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through mptsas1068 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/mptsas.c:968: void mptsas_interrupt_status_write(MPTSASState *): Assertion +`s->intr_status & MPI_HIS_DOORBELL_INTERRUPT' failed. +[1] 16951 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-5.2/build/qemu-system-i386 -m 512 -drive + +Program terminated with signal SIGABRT, Aborted. +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fc7d6023700 (LWP 23475))] +gdb-peda$ bt +#0 0x00007fc7efa13f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fc7efa158b1 in __GI_abort () at abort.c:79 +#2 0x00007fc7efa0542a in __assert_fail_base (fmt=0x7fc7efb8ca38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x56439214d593 "s->intr_status & MPI_HIS_DOORBELL_INTERRUPT", file=file@entry=0x56439214d4a7 "../hw/scsi/mptsas.c", line=line@entry=0x3c8, function=function@entry=0x56439214d81c "void mptsas_interrupt_status_write(MPTSASState *)") at assert.c:92 +#3 0x00007fc7efa054a2 in __GI___assert_fail (assertion=0x56439214d593 "s->intr_status & MPI_HIS_DOORBELL_INTERRUPT", file=0x56439214d4a7 "../hw/scsi/mptsas.c", line=0x3c8, function=0x56439214d81c "void mptsas_interrupt_status_write(MPTSASState *)") at assert.c:101 +#4 0x0000564391a43963 in mptsas_interrupt_status_write (s=<optimized out>) at ../hw/scsi/mptsas.c:968 +#5 0x0000564391a43963 in mptsas_mmio_write (opaque=0x5643943dd5b0, addr=0x30, val=0x18000000, size=<optimized out>) at ../hw/scsi/mptsas.c:1052 +#6 0x0000564391e08798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#7 0x0000564391e0858e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#8 0x0000564391e0858e in memory_region_dispatch_write (mr=0x5643943ddea0, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#9 0x0000564391eff228 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=<optimized out>, env=<optimized out>) + at ../accel/tcg/cputlb.c:1378 +#10 0x0000564391eff228 in store_helper (env=<optimized out>, addr=<optimized out>, val=<optimized out>, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2397 +#11 0x0000564391eff228 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x2, oi=<optimized out>, retaddr=0x7fc78841b401) at ../accel/tcg/cputlb.c:2463 +#12 0x00007fc78841b401 in code_gen_buffer () +#13 0x0000564391dd0da0 in cpu_tb_exec (cpu=0x56439363e650, itb=<optimized out>) at ../accel/tcg/cpu-exec.c:178 +#14 0x0000564391dd19eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#15 0x0000564391dd19eb in cpu_exec (cpu=0x56439363e650) at ../accel/tcg/cpu-exec.c:771 +#16 0x0000564391e00b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#17 0x0000564391e00b9f in tcg_cpu_thread_fn (arg=0x56439363e650) at ../accel/tcg/tcg-cpus.c:427 +#18 0x00005643920d8775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#19 0x00007fc7efdcd6db in start_thread (arg=0x7fc7d6023700) at pthread_create.c:463 + +To reproduce this issue, please run the QEMU with the following command line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line. +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device mptsas1068,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. +Thank you. + +- Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1908515 b/results/classifier/gemma3:12b/device/1908515 new file mode 100644 index 000000000..26ed9eea6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1908515 @@ -0,0 +1,70 @@ + +assertion failure in lsi53c810 emulator + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through lsi53c810 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/lsi53c895a.c:624: void lsi_do_dma(LSIState *, int): Assertion `s->current' +failed. +[1] 1406 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-5.2/build/i386-softmmu/qemu-system-i386 -m + +Program terminated with signal SIGABRT, Aborted. +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fa9310a8700 (LWP 2076))] +gdb-peda$ bt +#0 0x00007fa94aa98f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fa94aa9a8b1 in __GI_abort () at abort.c:79 +#2 0x00007fa94aa8a42a in __assert_fail_base (fmt=0x7fa94ac11a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x562851c9eab9 "s->current", file=file@entry=0x562851c9d4f9 "../hw/scsi/lsi53c895a.c", line=line@entry=0x270, function=function@entry=0x562851c9de43 "void lsi_do_dma(LSIState *, int)") at assert.c:92 +#3 0x00007fa94aa8a4a2 in __GI___assert_fail (assertion=0x562851c9eab9 "s->current", file=0x562851c9d4f9 "../hw/scsi/lsi53c895a.c", line=0x270, function=0x562851c9de43 "void lsi_do_dma(LSIState *, int)") + at assert.c:101 +#4 0x00005628515d9605 in lsi_do_dma (s=0x562855559060, out=0x1) at ../hw/scsi/lsi53c895a.c:624 +#5 0x00005628515d5317 in lsi_execute_script (s=<optimized out>) at ../hw/scsi/lsi53c895a.c:1250 +#6 0x00005628515cec49 in lsi_reg_writeb (s=0x562855559060, offset=0x2f, val=0x1e) + at ../hw/scsi/lsi53c895a.c:2005 +#7 0x0000562851952798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#8 0x000056285195258e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#9 0x000056285195258e in memory_region_dispatch_write (mr=0x562855559960, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#10 0x00005628518e5305 in flatview_write_continue (fv=0x7fa92871f040, addr=0xfebf302c, attrs=..., ptr=0x7fa9310a49b8, len=0x4, addr1=0x7fa9310a3410, l=<optimized out>, mr=0x562855559960) + at ../softmmu/physmem.c:2759 +#11 0x00005628518e6ef6 in flatview_write (fv=0x7fa92871f040, addr=0xfebf302c, attrs=..., len=0x4, buf=<optimized out>) at ../softmmu/physmem.c:2799 +#12 0x00005628518e6ef6 in subpage_write (opaque=<optimized out>, addr=<optimized out>, value=<optimized out>, len=<optimized out>, attrs=...) at ../softmmu/physmem.c:2465 +#13 0x00005628519529a2 in memory_region_write_with_attrs_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:511 +#14 0x00005628519525e1 in access_with_adjusted_size (addr=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, mr=<optimized out>, attrs=..., value=<optimized out>, access_fn=<optimized out>) at ../softmmu/memory.c:552 +#15 0x00005628519525e1 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1508 +#16 0x0000562851a49228 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=<optimized out>, env=<optimized out>) + at ../accel/tcg/cputlb.c:1378 +#17 0x0000562851a49228 in store_helper (env=<optimized out>, addr=<optimized out>, val=<optimized out>, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2397 +#18 0x0000562851a49228 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x2, oi=<optimized out>, retaddr=0x7fa8e44032ee) at ../accel/tcg/cputlb.c:2463 +#19 0x00007fa8e44032ee in code_gen_buffer () +#20 0x000056285191ada0 in cpu_tb_exec (cpu=0x5628547b81a0, itb=<optimized out>) + at ../accel/tcg/cpu-exec.c:178 +#21 0x000056285191b9eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#22 0x000056285191b9eb in cpu_exec (cpu=0x5628547b81a0) at ../accel/tcg/cpu-exec.c:771 +#23 0x000056285194ab9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#24 0x000056285194ab9f in tcg_cpu_thread_fn (arg=0x5628547b81a0) at ../accel/tcg/tcg-cpus.c:427 +#25 0x0000562851c22775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#26 0x00007fa94ae526db in start_thread (arg=0x7fa9310a8700) at pthread_create.c:463 +#27 0x00007fa94ab7ba3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +To reproduce this issue, please run the QEMU with the following command line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line. +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device lsi53c810,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. +Thank you. + +- Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1909247 b/results/classifier/gemma3:12b/device/1909247 new file mode 100644 index 000000000..ef4135083 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1909247 @@ -0,0 +1,30 @@ + +QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c + +A use-after-free vulnerability was found in the am53c974 SCSI host bus adapter emulation of QEMU. It could occur in the esp_do_dma() function in hw/scsi/esp.c while handling the 'Information Transfer' command (CMD_TI). A privileged guest user may abuse this flaw to crash the QEMU process on the host, resulting in a denial of service or potential code execution with the privileges of the QEMU process. + +This issue was reported by Cheolwoo Myung (Seoul National University). + +Original report: +Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in +am53c974 emulator of QEMU enabled ASan. + +It occurs while transferring information, as it does not check the +buffer to be transferred. + +A malicious guest user/process could use this flaw to crash the QEMU +process resulting in DoS scenario. + +To reproduce this issue, please run the QEMU with the following command +line. + +# To enable ASan option, please set configuration with the following +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ +-drive id=SysDisk,if=none,file=./disk.img + +Please find attached the disk images to reproduce this issue. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1909418 b/results/classifier/gemma3:12b/device/1909418 new file mode 100644 index 000000000..5b19b07f1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1909418 @@ -0,0 +1,189 @@ + +QEMU: Heap Overflow vulnerability in SDHCI Component + +Hello, i want to report qemu vulnerability in SDHCI component, this is integer overflow bug leads to oob read/write in the heap, that can happens in sdhci_do_adma or sdhci_sdma_transfer_multi_blocks. + +This is caused when in the middle of unfinished transfer, blksize can change, but the data_count still have the last offset of fifo_buffer from the last transfer. We change blksize to zero, then in the next transfer dma_memory_read/dma_memory_write in the first loop calculate length as blksize-data_count, this leads to integer overflow, because blksize is zero, and data_count can be more than zero. + +This bug is recorded in CVE-2020-25085, but the fix is not complete and not fix the root cause of the bug. + +Reproducer: +outl 0xcf8 0x80001010 +outl 0xcfc 0xd7055dba +outl 0xcf8 0x80001003 +outl 0xcfc 0x86b1d733 +write 0x00 0x1 0x29 +write 0x02 0x1 0x10 +write 0x08 0x1 0x39 +writeb 0xd7055d2b 0x5e +writel 0xd7055d2c 0xed7d735 +writew 0xd7055d30 0x126e +writeb 0xd7055d32 0x84 +writel 0xd7055d24 0xd7346e01 +writew 0xd7055d28 0x3bd7 +writeb 0xd7055d2a 0x1 +writeb 0xd7055d05 0x2c +writew 0xd7055d06 0x5c4 +writeb 0xd7055d0c 0x21 +writew 0xd7055d0e 0x846e +writel 0xd7055d04 0x260000 +writew 0xd7055d08 0x0 +writeb 0xd7055d0a 0x6d +writeb 0xd7055d0c 0x31 +clock_step +EOF + +➜ x86_64-softmmu git:(master) ✗ ./qemu-system-x86_64 -m 4G -nodefaults -trace 'sdhci*' -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -qtest stdio -accel qtest +==410717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 1609122395.789698] OPENED +qemu-system-x86_64: -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive: warning: bogus if=sd is deprecated, use if=none +[R +0.037381] outl 0xcf8 0x80001010 +[S +0.037436] OK +OK +[R +0.037470] outl 0xcfc 0xd7055dba +[S +0.037510] OK +OK +[R +0.037531] outl 0xcf8 0x80001003 +[S +0.037549] OK +OK +[R +0.037571] outl 0xcfc 0x86b1d733 +[S +0.039830] OK +OK +[R +0.039882] write 0x00 0x1 0x29 +[S +0.040364] OK +OK +[R +0.040401] write 0x02 0x1 0x10 +[S +0.040428] OK +OK +[R +0.040449] write 0x08 0x1 0x39 +[S +0.040472] OK +OK +[R +0.040491] writeb 0xd7055d2b 0x5e +[S +0.040530] OK +OK +[R +0.040550] writel 0xd7055d2c 0xed7d735 +[S +0.040575] OK +OK +[R +0.040594] writew 0xd7055d30 0x126e +[S +0.040620] OK +OK +[R +0.040638] writeb 0xd7055d32 0x84 +[S +0.040658] OK +OK +[R +0.040676] writel 0xd7055d24 0xd7346e01 +[S +0.040697] OK +OK +[R +0.040715] writew 0xd7055d28 0x3bd7 +[S +0.040738] OK +OK +[R +0.040756] writeb 0xd7055d2a 0x1 +[S +0.040779] OK +OK +[R +0.040797] writeb 0xd7055d05 0x2c +[S +0.040819] OK +OK +[R +0.040840] writew 0xd7055d06 0x5c4 +[S +0.040862] OK +OK +[R +0.040882] writeb 0xd7055d0c 0x21 +[S +0.040907] OK +OK +[R +0.040927] writew 0xd7055d0e 0x846e +[S +0.041026] OK +OK +[R +0.041054] writel 0xd7055d04 0x260000 +[S +0.041115] OK +OK +[R +0.041139] writew 0xd7055d08 0x0 +================================================================= +==410717==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000024180 at pc 0x7fe40cb7457d bp 0x7fffa1a7b800 sp 0x7fffa1a7afa8 +WRITE of size 786432 at 0x615000024180 thread T0 + #0 0x7fe40cb7457c (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c) + #1 0x55f804942120 in flatview_read_continue ../../softmmu/physmem.c:2829 + #2 0x55f8049423dd in flatview_read ../../softmmu/physmem.c:2862 + #3 0x55f804942581 in address_space_read_full ../../softmmu/physmem.c:2875 + #4 0x55f804942800 in address_space_rw ../../softmmu/physmem.c:2903 + #5 0x55f8038d6a92 in dma_memory_rw_relaxed /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:88 + #6 0x55f8038d6adf in dma_memory_rw /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:127 + #7 0x55f8038d6b17 in dma_memory_read /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:145 + #8 0x55f8038e47d9 in sdhci_do_adma ../../hw/sd/sdhci.c:807 + #9 0x55f8038e6081 in sdhci_data_transfer ../../hw/sd/sdhci.c:905 + #10 0x55f8038e694c in sdhci_resume_pending_transfer ../../hw/sd/sdhci.c:962 + #11 0x55f8038e9227 in sdhci_write ../../hw/sd/sdhci.c:1118 + #12 0x55f804856869 in memory_region_write_accessor ../../softmmu/memory.c:491 + #13 0x55f804856cf4 in access_with_adjusted_size ../../softmmu/memory.c:552 + #14 0x55f804863f28 in memory_region_dispatch_write ../../softmmu/memory.c:1501 + #15 0x55f8049419ce in flatview_write_continue ../../softmmu/physmem.c:2759 + #16 0x55f804941da4 in flatview_write ../../softmmu/physmem.c:2799 + #17 0x55f804942724 in address_space_write ../../softmmu/physmem.c:2891 + #18 0x55f804a9bee3 in qtest_process_command ../../softmmu/qtest.c:529 + #19 0x55f804aa0dea in qtest_process_inbuf ../../softmmu/qtest.c:797 + #20 0x55f804aa0edb in qtest_read ../../softmmu/qtest.c:809 + #21 0x55f804ffb687 in qemu_chr_be_write_impl ../../chardev/char.c:201 + #22 0x55f804ffb731 in qemu_chr_be_write ../../chardev/char.c:213 + #23 0x55f804fe5369 in fd_chr_read ../../chardev/char-fd.c:68 + #24 0x55f804f9b2dd in qio_channel_fd_source_dispatch ../../io/channel-watch.c:84 + #25 0x7fe40c548e8d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51e8d) + #26 0x55f80540b38e in glib_pollfds_poll ../../util/main-loop.c:221 + #27 0x55f80540b56f in os_host_main_loop_wait ../../util/main-loop.c:244 + #28 0x55f80540b871 in main_loop_wait ../../util/main-loop.c:520 + #29 0x55f80478602b in qemu_main_loop ../../softmmu/runstate.c:720 + #30 0x55f8038091c9 in main ../../softmmu/main.c:50 + #31 0x7fe409dc80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) + #32 0x55f8038090dd in _start (/home/n0p/belajar/qemu/source/qemu/bin/new/qemu-system-x86_64+0x28d10dd) + +0x615000024180 is located 0 bytes to the right of 512-byte region [0x615000023f80,0x615000024180) +allocated by thread T0 here: + #0 0x7fe40cbe6dc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6) + #1 0x7fe40c54ed30 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57d30) + #2 0x55f8040cd37b in sdhci_pci_realize ../../hw/sd/sdhci-pci.c:36 + #3 0x55f80411c6f5 in pci_qdev_realize ../../hw/pci/pci.c:2124 + #4 0x55f804fc7834 in device_set_realized ../../hw/core/qdev.c:761 + #5 0x55f804f8002c in property_set_bool ../../qom/object.c:2251 + #6 0x55f804f7a840 in object_property_set ../../qom/object.c:1399 + #7 0x55f804f83419 in object_property_set_qobject ../../qom/qom-qobject.c:28 + #8 0x55f804f7ae44 in object_property_set_bool ../../qom/object.c:1466 + #9 0x55f804fc417a in qdev_realize ../../hw/core/qdev.c:389 + #10 0x55f803da8bb7 in qdev_device_add ../../softmmu/qdev-monitor.c:665 + #11 0x55f8047f5408 in device_init_func ../../softmmu/vl.c:1201 + #12 0x55f8053d3644 in qemu_opts_foreach ../../util/qemu-option.c:1147 + #13 0x55f8047fc593 in qemu_create_cli_devices ../../softmmu/vl.c:2488 + #14 0x55f8047fc6fa in qmp_x_exit_preconfig ../../softmmu/vl.c:2527 + #15 0x55f804801c8e in qemu_init ../../softmmu/vl.c:3534 + #16 0x55f8038091c4 in main ../../softmmu/main.c:49 + #17 0x7fe409dc80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) + +SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c) +Shadow bytes around the buggy address: + 0x0c2a7fffc7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c2a7fffc7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffc800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffc810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffc820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c2a7fffc830:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c2a7fffc840: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffc850: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffc860: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffc870: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffc880: 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 +==410717==ABORTING \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1910586 b/results/classifier/gemma3:12b/device/1910586 new file mode 100644 index 000000000..8018a01b6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1910586 @@ -0,0 +1,46 @@ + +SD card size constraint conceptually wrong + +The patch discussed here: +https://<email address hidden>/msg720833.html +introduces an artificial size constraint for SD cards +that has no relation to reality. + +I'm trying to use an _actual_ **physical** SD card, +and qemu tells me its size is "invalid". + +Something here appears to be conceptually wrong. + +-------------------------------------------------- +# fdisk -l /dev/sdg +Disk /dev/sdg: 14.84 GiB, 15931539456 bytes, 31116288 sectors +Disk model: USB SD Reader +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: dos +Disk identifier: 0x7a0c8bb0 + +Device Boot Start End Sectors Size Id Type +/dev/sdg1 2048 524287 522240 255M c W95 FAT32 (LBA) +/dev/sdg2 524288 31116287 30592000 14.6G 83 Linux +# qemu-system-aarch64 -M raspi3 -m 1G -kernel vmlinuz-5.4.79-v8 -dtb bcm2837-rpi-3-b-plus.dtb -append console=ttyAMA0\ root=/dev/mmcblk0p2\ rw -nographic -serial mon:stdio -drive file=/dev/sdg,format=raw +qemu-system-aarch64: Invalid SD card size: 14.8 GiB +SD card size has to be a power of 2, e.g. 16 GiB. +You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +(note that this will lose data if you make the image smaller than it currently is). +-------------------------------------------------- + +The same invocation with a dump of the actual image +resized to match qemu's odd expectations works fine. + + +This is on QEMU 5.2.0, as evidenced by the following: +-------------------------------------------------- +# qemu-system-aarch64 -version +QEMU emulator version 5.2.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +-------------------------------------------------- + +Is there a simple workaround that disables this rather +arbitrary constraint? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1910603 b/results/classifier/gemma3:12b/device/1910603 new file mode 100644 index 000000000..f524d7f9c --- /dev/null +++ b/results/classifier/gemma3:12b/device/1910603 @@ -0,0 +1,45 @@ + +[OSS-Fuzz] Issue 29174 sb16: Abrt in audio_bug + +=== Reproducer === +cat << EOF | ../build-system/qemu-system-i386 \ +-machine q35 -device sb16,audiodev=snd0 \ +-audiodev none,id=snd0 -nographic -nodefaults \ +-qtest stdio +outw 0x22c 0x41 +outb 0x22c 0x0 +outw 0x22c 0x1004 +outw 0x22c 0x1c +EOF + +=== Stack Trace === +A bug was just triggered in audio_calloc +Save all your work and restart without audio +I am sorry +Context: +Aborted + +#0 raise +#1 abort +#2 audio_bug /src/qemu/audio/audio.c:119:9 +#3 audio_calloc /src/qemu/audio/audio.c:154:9 +#4 audio_pcm_sw_alloc_resources_out /src/qemu/audio/audio_template.h:116:15 +#5 audio_pcm_sw_init_out /src/qemu/audio/audio_template.h:175:11 +#6 audio_pcm_create_voice_pair_out /src/qemu/audio/audio_template.h:410:9 +#7 AUD_open_out /src/qemu/audio/audio_template.h:503:14 +#8 continue_dma8 /src/qemu/hw/audio/sb16.c:216:20 +#9 dma_cmd8 /src/qemu/hw/audio/sb16.c:276:5 +#10 command /src/qemu/hw/audio/sb16.c:0 +#11 dsp_write /src/qemu/hw/audio/sb16.c:949:13 +#12 portio_write /src/qemu/softmmu/ioport.c:205:13 +#13 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#14 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#15 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#16 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#17 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#18 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#19 cpu_outw /src/qemu/softmmu/ioport.c:70:5 + + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29174 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1910605 b/results/classifier/gemma3:12b/device/1910605 new file mode 100644 index 000000000..967e82b35 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1910605 @@ -0,0 +1,17 @@ + +qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address + + + +Snippet of code sample: + +struct usbdevfs_bulktransfer Bulk; +Bulk.ep = hUsb->UsbOut; +Bulk.len = Len; +Bulk.data = (void *)pData; +Bulk.timeout = Timeout; +Bytes = ioctl(hUsb->fd, USBDEVFS_BULK, &Bulk) + +The above code sample return -1 (EFAULT) Bad address when using qemu-arm-static but is running ok when on qemu-aarch64-static. + +I use a 64-bit intel laptop \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1910723 b/results/classifier/gemma3:12b/device/1910723 new file mode 100644 index 000000000..f3beb765b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1910723 @@ -0,0 +1,71 @@ + +NULL pointer dereference issues in am53c974 SCSI host bus adapter + +Two NULL pointer dereference issues were found in the am53c974 SCSI host bus adapter emulation of QEMU. They could occur while handling the 'Information Transfer' command (CMD_TI) in function handle_ti() in hw/scsi/esp.c, and could be abused by a malicious guest to crash the QEMU process on the host resulting in a denial of service. + +Both issues were reported by Cheolwoo Myung (Seoul National University). To reproduce them, configure and run QEMU as follows. Please find attached the required disk images. + +$ ./configure --target-list=x86_64-softmmu --enable-kvm --enable-sanitizers +$ make +$ ./qemu-system-x86_64 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ +-drive id=SysDisk,if=none,file=./disk.img + +Additional info: +RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909766 +RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909769 + +ASAN logs: +==672133== +hw/scsi/scsi-bus.c:1385:12: runtime error: member access within null pointer of type 'struct SCSIRequest' +AddressSanitizer:DEADLYSIGNAL +================================================================= +==672133==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000171 (pc 0x55bd63e20b85 bp 0x7f4b6fffdfa0 sp 0x7f4b6fffdf70 T7) +==672133==The signal is caused by a READ memory access. +==672133==Hint: address points to the zero page. + #0 0x55bd63e20b85 in scsi_req_continue hw/scsi/scsi-bus.c:1385 + #1 0x55bd63ab34fb in esp_do_dma hw/scsi/esp.c:453 + #2 0x55bd63ab4b3c in handle_ti hw/scsi/esp.c:549 + #3 0x55bd63ab72a9 in esp_reg_write hw/scsi/esp.c:691 + #4 0x55bd63d7b5dd in esp_pci_io_write hw/scsi/esp-pci.c:206 + #5 0x55bd645d55a3 in memory_region_write_accessor softmmu/memory.c:491 + #6 0x55bd645d5a24 in access_with_adjusted_size softmmu/memory.c:552 + #7 0x55bd645e2baa in memory_region_dispatch_write softmmu/memory.c:1501 + #8 0x55bd646b75ff in flatview_write_continue softmmu/physmem.c:2759 + #9 0x55bd646b79d1 in flatview_write softmmu/physmem.c:2799 + #10 0x55bd646b8341 in address_space_write softmmu/physmem.c:2891 + #11 0x55bd646b83f9 in address_space_rw softmmu/physmem.c:2901 + #12 0x55bd648c4736 in kvm_handle_io accel/kvm/kvm-all.c:2285 + #13 0x55bd648c69c8 in kvm_cpu_exec accel/kvm/kvm-all.c:2531 + #14 0x55bd647b2413 in kvm_vcpu_thread_fn accel/kvm/kvm-cpus.c:49 + #15 0x55bd64f560de in qemu_thread_start util/qemu-thread-posix.c:521 + #16 0x7f4b981763f8 in start_thread (/lib64/libpthread.so.0+0x93f8) + #17 0x7f4b980a3902 in __GI___clone (/lib64/libc.so.6+0x101902) + +--- + +==672020== +hw/scsi/esp.c:196:62: runtime error: member access within null pointer of type 'struct SCSIDevice' +AddressSanitizer:DEADLYSIGNAL +================================================================= +==672020==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000098 (pc 0x559bc99946fd bp 0x7f08bd737fb0 sp 0x7f08bd737f70 T7) +==672020==The signal is caused by a READ memory access. +==672020==Hint: address points to the zero page. + #0 0x559bc99946fd in do_busid_cmd hw/scsi/esp.c:196 + #1 0x559bc9994e71 in do_cmd hw/scsi/esp.c:220 + #2 0x559bc999ae81 in handle_ti hw/scsi/esp.c:555 + #3 0x559bc999d2a9 in esp_reg_write hw/scsi/esp.c:691 + #4 0x559bc9c615dd in esp_pci_io_write hw/scsi/esp-pci.c:206 + #5 0x559bca4bb5a3 in memory_region_write_accessor softmmu/memory.c:491 + #6 0x559bca4bba24 in access_with_adjusted_size softmmu/memory.c:552 + #7 0x559bca4c8baa in memory_region_dispatch_write softmmu/memory.c:1501 + #8 0x559bca59d5ff in flatview_write_continue softmmu/physmem.c:2759 + #9 0x559bca59d9d1 in flatview_write softmmu/physmem.c:2799 + #10 0x559bca59e341 in address_space_write softmmu/physmem.c:2891 + #11 0x559bca59e3f9 in address_space_rw softmmu/physmem.c:2901 + #12 0x559bca7aa736 in kvm_handle_io accel/kvm/kvm-all.c:2285 + #13 0x559bca7ac9c8 in kvm_cpu_exec accel/kvm/kvm-all.c:2531 + #14 0x559bca698413 in kvm_vcpu_thread_fn accel/kvm/kvm-cpus.c:49 + #15 0x559bcae3c0de in qemu_thread_start util/qemu-thread-posix.c:521 + #16 0x7f08e57ba3f8 in start_thread (/lib64/libpthread.so.0+0x93f8) + #17 0x7f08e56e7902 in __GI___clone (/lib64/libc.so.6+0x101902) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1910941 b/results/classifier/gemma3:12b/device/1910941 new file mode 100644 index 000000000..f153a6846 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1910941 @@ -0,0 +1,58 @@ + +Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through virtio-blk emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + +``` + +qemu-system-i386: /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +[1] 1877 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-master/build/i386-softmmu/qemu-system-i386 + +Program terminated with signal SIGABRT, Aborted. +#0 0x00007f71cc171f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f71cc1738b1 in __GI_abort () at abort.c:79 +#2 0x00007f71cc16342a in __assert_fail_base (fmt=0x7f71cc2eaa38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=file@entry=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=line@entry=0x58, function=function@entry=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:92 +#3 0x00007f71cc1634a2 in __GI___assert_fail (assertion=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=0x58, function=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:101 +#4 0x000056537af3c917 in address_space_stw_le_cached (attrs=..., result=<optimized out>, cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88 +#5 0x000056537af3c917 in stw_le_phys_cached (cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_phys.h.inc:121 +#6 0x000056537af3c917 in virtio_stw_phys_cached (vdev=<optimized out>, cache=<optimized out>, pa=<optimized out>, value=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/hw/virtio/virtio-access.h:196 +#7 0x000056537af2b809 in vring_set_avail_event (vq=<optimized out>, val=0x0) at ../hw/virtio/virtio.c:429 +#8 0x000056537af2b809 in virtio_queue_split_set_notification (vq=<optimized out>, enable=<optimized out>) at ../hw/virtio/virtio.c:438 +#9 0x000056537af2b809 in virtio_queue_set_notification (vq=<optimized out>, enable=0x1) at ../hw/virtio/virtio.c:499 +#10 0x000056537b07ce1c in virtio_blk_handle_vq (s=0x56537d6bb3a0, vq=0x56537d6c0680) at ../hw/block/virtio-blk.c:795 +#11 0x000056537af3eb4d in virtio_queue_notify_aio_vq (vq=0x56537d6c0680) at ../hw/virtio/virtio.c:2326 +#12 0x000056537af3ba04 in virtio_queue_host_notifier_aio_read (n=<optimized out>) at ../hw/virtio/virtio.c:3533 +#13 0x000056537b20901c in aio_dispatch_handler (ctx=0x56537c4179f0, node=0x7f71a810b370) at ../util/aio-posix.c:329 +#14 0x000056537b20838c in aio_dispatch_handlers (ctx=<optimized out>) at ../util/aio-posix.c:372 +#15 0x000056537b20838c in aio_dispatch (ctx=0x56537c4179f0) at ../util/aio-posix.c:382 +#16 0x000056537b1f99cb in aio_ctx_dispatch (source=0x2, callback=0x7ffc8add9f90, user_data=0x0) at ../util/async.c:306 +#17 0x00007f71d1c10417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#18 0x000056537b1f1bab in glib_pollfds_poll () at ../util/main-loop.c:232 +#19 0x000056537b1f1bab in os_host_main_loop_wait (timeout=<optimized out>) at ../util/main-loop.c:255 +#20 0x000056537b1f1bab in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531 +#21 0x000056537af879d7 in qemu_main_loop () at ../softmmu/runstate.c:720 +#22 0x000056537a928a3b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, argv@entry=0x7ffc8adda718, envp=<optimized out>) at ../softmmu/main.c:50 +#23 0x00007f71cc154b97 in __libc_start_main (main=0x56537a928a30 <main>, argc=0x15, argv=0x7ffc8adda718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc8adda708) at ../csu/libc-start.c:310 +#24 0x000056537a92894a in _start () + +``` + +To reproduce this issue, please run the QEMU with the following command line. + +``` + +# To reproduce this issue, please run the QEMU process with the following command line. + +$ qemu-system-i386 -m 512 -drive file=hyfuzz.img,index=0,media=disk,format=raw -device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 -drive file=disk.img,if=none,id=drive0 + +``` + +Please let me know if I can provide any further info. + +Thank you. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1911075 b/results/classifier/gemma3:12b/device/1911075 new file mode 100644 index 000000000..c4246b4c2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1911075 @@ -0,0 +1,66 @@ + +[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines + +=== Reproducer === +while true; do cat << EOF; done | ./qemu-system-i386 -machine q35 -nodefaults -nographic -qtest stdio -accel qtest +outl 0xcf8 0x8000fa27 +outl 0xcfc 0x37414537 +outl 0xcf8 0x8000fa01 +outl 0xcfc 0x4606ce74 +writew 0x37000f01 0x215a +writeq 0x37000100 0xfffaf +writeq 0x37000115 0xffff373d27004037 +outl 0xcf8 0x8000fa01 +outl 0xcfc 0x4606ce74 +writeq 0x370000ff 0x3700011500 +writeq 0x37000115 0xc41ffffff035a5a +outl 0xcf8 0x8000ea04 +outb 0xcfc 0x15 +outl 0xcf8 0x8000ea00 +outw 0xcfc 0x5a1f +writeq 0x37000115 0x100007765746972 +writeq 0x37000115 0xbf00000000000000 +outl 0xcf8 0x8000ea04 +outb 0xcfc 0x15 +outl 0xcf8 0x8000fa46 +outb 0xcfc 0xff +clock_step +writeq 0x37000115 0xaf +writeq 0x37000115 0x6301275541af7415 +writeq 0x37000115 0xafaf5a5a743715 +outb 0x64 0xfe +EOF + +=== Stack Trace === +==887446==ERROR: UndefinedBehaviorSanitizer: stack-overflow on address 0x7ffe567cae0c (pc 0x7fdd9100819e bp 0x7ffe567cb2b0 sp 0x7ffe567cad40 T887446) + +#0 vfprintf +#1 fprintf +#2 ahci_mem_write /src/qemu/hw/ide/ahci.c:468:9 +#3 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#4 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#5 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#6 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#7 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#8 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#9 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9 +#10 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5 +#11 map_page /src/qemu/hw/ide/ahci.c:249:9 +#12 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5 +#13 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14 +#14 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9 +#15 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9 +#16 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#17 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#18 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#19 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#20 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#21 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#22 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9 +#23 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5 +#24 map_page /src/qemu/hw/ide/ahci.c:249:9 +#25 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5 +#26 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14 +#27 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9 +#28 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9 +... Repeat until we run out of stack \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1912780 b/results/classifier/gemma3:12b/device/1912780 new file mode 100644 index 000000000..1824a636e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1912780 @@ -0,0 +1,79 @@ + +QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c + +[via qemu-security list] + +This is Gaoning Pan from Zhejiang University & Ant Security Light-Year Lab. +I found a Null Pointer issue locates in fdctrl_read() in hw/block/fdc.c. +This flaw allows a malicious guest user or process in a denial of service condition. + +This issus was discovered in the latest Qemu-5.2.0. When using floppy device, there are several +choices to get specific drive in get_drv(), depending on fdctrl->cur_drv. But not all drives are +initialized properly, leaving fdctrl->drives[0]->blk as NULL. So when the drive was used in +blk_pread(cur_drv->blk, fd_offset(cur_drv), fdctrl->fifo, BDRV_SECTOR_SIZE) at line 1918, +null pointer access triggers, thus denial of service.My reproduced environment is as follows: + + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +My boot command is as follows: + + qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img \ + -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device floppy,unit=1,drive=mydrive \ + -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none -display none + +ASAN output is as follows: +================================================================= +==14688==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000034c (pc 0x5636eee9bbaf bp 0x7ff2a53fdea0 sp 0x7ff2a53fde90 T3) +==14688==The signal is caused by a WRITE memory access. +==14688==Hint: address points to the zero page. + #0 0x5636eee9bbae in blk_inc_in_flight ../block/block-backend.c:1356 + #1 0x5636eee9b766 in blk_prw ../block/block-backend.c:1328 + #2 0x5636eee9cd76 in blk_pread ../block/block-backend.c:1491 + #3 0x5636ee1adf24 in fdctrl_read_data ../hw/block/fdc.c:1918 + #4 0x5636ee1a6654 in fdctrl_read ../hw/block/fdc.c:935 + #5 0x5636eebb84c8 in portio_read ../softmmu/ioport.c:179 + #6 0x5636ee9848c5 in memory_region_read_accessor ../softmmu/memory.c:442 + #7 0x5636ee9855c2 in access_with_adjusted_size ../softmmu/memory.c:552 + #8 0x5636ee98f0b7 in memory_region_dispatch_read1 ../softmmu/memory.c:1420 + #9 0x5636ee98f311 in memory_region_dispatch_read ../softmmu/memory.c:1449 + #10 0x5636ee8ff64a in flatview_read_continue ../softmmu/physmem.c:2822 + #11 0x5636ee8ff9e5 in flatview_read ../softmmu/physmem.c:2862 + #12 0x5636ee8ffb83 in address_space_read_full ../softmmu/physmem.c:2875 + #13 0x5636ee8ffdeb in address_space_rw ../softmmu/physmem.c:2903 + #14 0x5636eea6a924 in kvm_handle_io ../accel/kvm/kvm-all.c:2285 + #15 0x5636eea6c5e3 in kvm_cpu_exec ../accel/kvm/kvm-all.c:2531 + #16 0x5636eeca492b in kvm_vcpu_thread_fn ../accel/kvm/kvm-cpus.c:49 + #17 0x5636ef1bc296 in qemu_thread_start ../util/qemu-thread-posix.c:521 + #18 0x7ff337c736da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da) + #19 0x7ff33799ca3e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x121a3e) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV ../block/block-backend.c:1356 in blk_inc_in_flight +Thread T3 created by T0 here: + #0 0x7ff33c580d2f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37d2f) + #1 0x5636ef1bc673 in qemu_thread_create ../util/qemu-thread-posix.c:558 + #2 0x5636eeca4ce7 in kvm_start_vcpu_thread ../accel/kvm/kvm-cpus.c:73 + #3 0x5636ee9aa965 in qemu_init_vcpu ../softmmu/cpus.c:622 + #4 0x5636ee82a9b4 in x86_cpu_realizefn ../target/i386/cpu.c:6731 + #5 0x5636eed002f4 in device_set_realized ../hw/core/qdev.c:886 + #6 0x5636eecc59bc in property_set_bool ../qom/object.c:2251 + #7 0x5636eecc0c28 in object_property_set ../qom/object.c:1398 + #8 0x5636eecb6fb9 in object_property_set_qobject ../qom/qom-qobject.c:28 + #9 0x5636eecc1175 in object_property_set_bool ../qom/object.c:1465 + #10 0x5636eecfc286 in qdev_realize ../hw/core/qdev.c:399 + #11 0x5636ee739b34 in x86_cpu_new ../hw/i386/x86.c:111 + #12 0x5636ee739d6d in x86_cpus_init ../hw/i386/x86.c:138 + #13 0x5636ee6f843e in pc_init1 ../hw/i386/pc_piix.c:159 + #14 0x5636ee6fab1e in pc_init_v5_2 ../hw/i386/pc_piix.c:438 + #15 0x5636ee1cb4a7 in machine_run_board_init ../hw/core/machine.c:1134 + #16 0x5636ee9c323d in qemu_init ../softmmu/vl.c:4369 + #17 0x5636edd92c71 in main ../softmmu/main.c:49 + #18 0x7ff33789cb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) + +==14688==ABORTING + +Reproducer is attached. + +Best regards. +Gaoning Pan of Zhejiang University & Ant Security Light-Year Lab \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1912846 b/results/classifier/gemma3:12b/device/1912846 new file mode 100644 index 000000000..ec91bf4c7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1912846 @@ -0,0 +1,18 @@ + +Assertion hit on hot-unplugging virtio iommu enabled device + +From commit ("2d24a646 device-core: use RCU for +list of children of a bus") an assertion is hit when +removing a device, since mr->listeners are not properly +removed. To reproduce: + +/home/qemu/build/x86_64-softmmu/qemu-system-x86_64 -qmp tcp:0:4444,server,nowait ... \ + -netdev tap,id=hostnet0,vhostforce=on,vhost=on \ + -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:14:18:cc,bus=pci.1,addr=0x0,iommu_platform=on,ats=on + +In QMP: +{'execute': 'qmp_capabilities'} +{"execute": "device_del", "arguments": {"id": "net0"} } + +And crash: +../softmmu/memory.c:2818: do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913341 b/results/classifier/gemma3:12b/device/1913341 new file mode 100644 index 000000000..9b5d9afd6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913341 @@ -0,0 +1,24 @@ + +Chardev behavior breaks polling based devices + +Currently in latest QEMU (9cd69f1a270235b652766f00b94114f48a2d603f at this time) the behavior of chardev sources is that when processed (before IO polling occurs), the chardev source will check the amount of space for reading. + +If it reports more than 0 bytes available to accept the read and a callback is not set, the code will set a child source connected to the QIOChannel submitted to the original source. If there's no buffer space reported, it will check for an active source, if registered it will detach this source. + +Next time the loop fires, if the buffer now reports space (most likely the guest has run, emptying some bytes from the buffer), it will setup the callback again. + +However, if we have a stupid simple device (or driver) that doesn't have buffers big enough to fit an available write when one is sent (say a single byte buffer, polled serial port), then the poll will be set, the poll will occur and return quickly, then the callback will (depending on the backend chardev used) most likely read the 1 byte it has space for from the source, push it over to the frontend hardware side, and the IO loop will run again. + +Most likely the guest will not clear this byte before the next io loop cycle, meaning that the next prepare call on the source will see a full buffer in the guest and remove the poll for the data source, to allow the guest time to run to clear the buffer. Except, without a poll or a timeout set, the io loop might now block forever, since there's no report from the guest after clearing that buffer. This only returns in a sane amount of time because often some other device/timer is scheduled which sets a timeout on the poll to a reasonable time. + +I don't have a simple submittable bit of code to replicate at the moment but connecting a serial port to a pty then writing a large amount of data, while a guest that doesn't enable the fifo spins on an rx ready register, you can observe that RX on the guest takes anywhere from 1s to forever per byte. + +This logic all occurs in chardev/char-io.c + +Fixing this can be as simple as removing the logic to detach the child event source and changing the attach logic to only occur if there's buffer space and the poll isn't already setup. That fix could cause flow control issues potentially if the io runs on the same thread as the emulated guest (I am not sure about the details of this) and the guest is in a tight loop doing the poll. I don't see that as happening but the logic might be there for a reason. + +Another option is to set a timeout when the source gets removed, forcing the poll to exit with a fixed delay, this delay could potentially be derived from something like the baud rate set, forcing a minimum time before forward progress. + +If removing the logic isn't an option, another solution is to make the emulated hardware code itself kick the IO loop and trigger it to reschedule the poll. Similar to how the non-blocking write logic works, the read logic could recognize when the buffer has been emptied and reschedule the hw on the guest. In theory this sounds nice, but for it to work would require adding logic to all the emulated chardev frontends and in reality would likely be going through the effort to remove the callback only to within a few nanoseconds potentially want to add it back. + +I'm planning to submit a patch with just outright removing the logic, but am filing this bug as a place to reference since tracking down this problem is non-obvious. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913510 b/results/classifier/gemma3:12b/device/1913510 new file mode 100644 index 000000000..e2bd9e8b6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913510 @@ -0,0 +1,102 @@ + +[Fuzz] qemu-system-i386 virtio-mouse: Assertion in address_space_lduw_le_cached failed + +--[ Reproducer + +cat << EOF | ./build/qemu-system-i386 -machine q35,accel=qtest -nodefaults \ +-device virtio-mouse -display none -qtest stdio +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0004000 +outl 0xcf8 0x80000804 +outb 0xcfc 0x02 +write 0xe000400c 0x4 0x003fe62e +write 0xe0004016 0x1 0x01 +write 0xe0004024 0x1 0x01 +write 0xe000401c 0x1 0x01 +write 0xe0007007 0x1 0x00 +write 0xe0004018 0x1 0x41 +write 0xe0007007 0x1 0x00 +EOF + + +--[ Output + +[I 1611805425.711054] OPENED +[R +0.040080] outl 0xcf8 0x80000820 +OK +[S +0.040117] OK +[R +0.040136] outl 0xcfc 0xe0004000 +OK +[S +0.040155] OK +[R +0.040165] outl 0xcf8 0x80000804 +OK +[S +0.040172] OK +[R +0.040184] outb 0xcfc 0x02 +OK +[S +0.040683] OK +[R +0.040702] write 0xe000400c 0x4 0x003fe62e +OK +[S +0.040735] OK +[R +0.040743] write 0xe0004016 0x1 0x01 +OK +[S +0.040748] OK +[R +0.040755] write 0xe0004024 0x1 0x01 +OK +[S +0.040760] OK +[R +0.040767] write 0xe000401c 0x1 0x01 +OK +[S +0.040785] OK +[R +0.040792] write 0xe0007007 0x1 0x00 +OK +[S +0.040810] OK +[R +0.040817] write 0xe0004018 0x1 0x41 +OK +[S +0.040822] OK +[R +0.040839] write 0xe0007007 0x1 0x00 +qemu-system-i386: /home/ubuntu/qemu/include/exec/memory_ldst_cached.h.inc:54: uint32_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + + +-- [ Original ASAN report + +qemu-fuzz-i386: /home/ubuntu/qemu/include/exec/memory_ldst_cached.h.inc:54: uint32_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +==3406167== ERROR: libFuzzer: deadly signal + #0 0x5644e4ae0f21 in __sanitizer_print_stack_trace (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2a47f21) + #1 0x5644e4a29fe8 in fuzzer::PrintStackTrace() (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2990fe8) + #2 0x5644e4a10023 in fuzzer::Fuzzer::CrashCallback() (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2977023) + #3 0x7f77e2a4b3bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) + #4 0x7f77e285c18a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a) + #5 0x7f77e283b858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858) + #6 0x7f77e283b728 (/lib/x86_64-linux-gnu/libc.so.6+0x25728) + #7 0x7f77e284cf35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35) + #8 0x5644e60051b2 in address_space_lduw_le_cached /home/ubuntu/qemu/include/exec/memory_ldst_cached.h.inc:54:5 + #9 0x5644e60051b2 in lduw_le_phys_cached /home/ubuntu/qemu/include/exec/memory_ldst_phys.h.inc:91:12 + #10 0x5644e60051b2 in virtio_lduw_phys_cached /home/ubuntu/qemu/include/hw/virtio/virtio-access.h:166:12 + #11 0x5644e5ff476d in vring_avail_ring /home/ubuntu/qemu/build/../hw/virtio/virtio.c:327:12 + #12 0x5644e5ff476d in vring_get_used_event /home/ubuntu/qemu/build/../hw/virtio/virtio.c:333:12 + #13 0x5644e5ff476d in virtio_split_should_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2473:35 + #14 0x5644e5ff476d in virtio_should_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2524:16 + #15 0x5644e5ff5556 in virtio_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2566:14 + #16 0x5644e5571d2a in virtio_input_handle_sts /home/ubuntu/qemu/build/../hw/input/virtio-input.c:100:5 + #17 0x5644e5ff20ec in virtio_queue_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2366:9 + #18 0x5644e60908fb in memory_region_write_accessor /home/ubuntu/qemu/build/../softmmu/memory.c:491:5 + #19 0x5644e6090363 in access_with_adjusted_size /home/ubuntu/qemu/build/../softmmu/memory.c:552:18 + #20 0x5644e608fbc0 in memory_region_dispatch_write /home/ubuntu/qemu/build/../softmmu/memory.c + #21 0x5644e5b97bc6 in flatview_write_continue /home/ubuntu/qemu/build/../softmmu/physmem.c:2759:23 + #22 0x5644e5b8d328 in flatview_write /home/ubuntu/qemu/build/../softmmu/physmem.c:2799:14 + #23 0x5644e5b8d328 in address_space_write /home/ubuntu/qemu/build/../softmmu/physmem.c:2891:18 + #24 0x5644e6018906 in qtest_process_command /home/ubuntu/qemu/build/../softmmu/qtest.c:539:13 + #25 0x5644e60159df in qtest_process_inbuf /home/ubuntu/qemu/build/../softmmu/qtest.c:797:9 + #26 0x5644e6015735 in qtest_server_inproc_recv /home/ubuntu/qemu/build/../softmmu/qtest.c:904:9 + #27 0x5644e667cf68 in qtest_sendf /home/ubuntu/qemu/build/../tests/qtest/libqtest.c:438:5 + #28 0x5644e667e54e in qtest_write /home/ubuntu/qemu/build/../tests/qtest/libqtest.c:1002:5 + #29 0x5644e667e54e in qtest_writeq /home/ubuntu/qemu/build/../tests/qtest/libqtest.c:1023:5 + #30 0x5644e4b1037e in __wrap_qtest_writeq /home/ubuntu/qemu/build/../tests/qtest/fuzz/qtest_wrappers.c:190:9 + #31 0x5644e4b1c33d in op_write /home/ubuntu/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:479:13 + #32 0x5644e4b1a259 in generic_fuzz /home/ubuntu/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:681:17 + #33 0x5644e4b0b333 in LLVMFuzzerTestOneInput /home/ubuntu/qemu/build/../tests/qtest/fuzz/fuzz.c:151:5 + #34 0x5644e4a11581 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2978581) + #35 0x5644e49fcc92 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2963c92) + #36 0x5644e4a02cfe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2969cfe) + #37 0x5644e4a2a7c2 in main (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x29917c2) + #38 0x7f77e283d0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) + #39 0x5644e49d739d in _start (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x293e39d) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913667 b/results/classifier/gemma3:12b/device/1913667 new file mode 100644 index 000000000..03f08dc2b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913667 @@ -0,0 +1,37 @@ + +FPE in npcm7xx_clk_update_pll + +I've been working on integrating the generic-fuzzer with ARM machines on OSS-Fuzz so we can fuzz devices on architectures beyond i386 devices. Since I saw that there is some active development for the Nuvoton machines, I thought it might be useful to fuzz the NPCM750 machine + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf080100c 0x4 0x00 +write 0xf080100c 0x4 0x00 +EOF + +Trace: +../hw/misc/npcm7xx_clk.c:131:14: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_clk.c:131:14 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717855==ERROR: AddressSanitizer: FPE on unknown address 0x5619201fcd8c (pc 0x5619201fcd8c bp 0x7ffc94214e50 sp 0x7ffc94214e30 T0) +#0 0x5619201fcd8c in npcm7xx_clk_update_pll /hw/misc/npcm7xx_clk.c:131:14 +#1 0x5619201ff5dc in npcm7xx_clk_write /hw/misc/npcm7xx_clk.c:799:13 +#2 0x5619214781fe in memory_region_write_accessor /softmmu/memory.c:491:5 +#3 0x561921477bfb in access_with_adjusted_size /softmmu/memory.c:552:18 +#4 0x561921477467 in memory_region_dispatch_write /softmmu/memory.c +#5 0x561921807ffb in flatview_write_continue /softmmu/physmem.c:2759:23 +#6 0x5619217fd71b in flatview_write /softmmu/physmem.c:2799:14 +#7 0x5619217fd71b in address_space_write /softmmu/physmem.c:2891:18 +#8 0x561921465eee in qtest_process_command /softmmu/qtest.c:539:13 +#9 0x561921462b97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#10 0x561921cb3286 in fd_chr_read /chardev/char-fd.c:68:9 +#11 0x7f4ad283baae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#12 0x56192230e363 in glib_pollfds_poll /util/main-loop.c:232:9 +#13 0x56192230e363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#14 0x56192230e363 in main_loop_wait /util/main-loop.c:531:11 +#15 0x5619213c9599 in qemu_main_loop /softmmu/runstate.c:721:9 +#16 0x56191f6561fd in main /softmmu/main.c:50:5 +#17 0x7f4ad22e0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#18 0x56191f5a9bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913668 b/results/classifier/gemma3:12b/device/1913668 new file mode 100644 index 000000000..3c0be2b35 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913668 @@ -0,0 +1,36 @@ + +FPE in npcm7xx_pwm_calculate_freq + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf0103008 0x4 0x09000000 +write 0xf010300c 0x4 0xffffffff +EOF + +Trace: +../hw/misc/npcm7xx_pwm.c:94:17: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_pwm.c:94:17 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717868==ERROR: AddressSanitizer: FPE on unknown address 0x5597c7190150 (pc 0x5597c7190150 bp 0x7fffcb17c5d0 sp 0x7fffcb17c4e0 T0) +#0 0x5597c7190150 in npcm7xx_pwm_calculate_freq /hw/misc/npcm7xx_pwm.c:94:17 +#1 0x5597c7190150 in npcm7xx_pwm_update_freq /hw/misc/npcm7xx_pwm.c:122:21 +#2 0x5597c718f06d in npcm7xx_pwm_write /hw/misc/npcm7xx_pwm.c +#3 0x5597c8d241fe in memory_region_write_accessor /softmmu/memory.c:491:5 +#4 0x5597c8d23bfb in access_with_adjusted_size /softmmu/memory.c:552:18 +#5 0x5597c8d23467 in memory_region_dispatch_write /softmmu/memory.c +#6 0x5597c90b3ffb in flatview_write_continue /softmmu/physmem.c:2759:23 +#7 0x5597c90a971b in flatview_write /softmmu/physmem.c:2799:14 +#8 0x5597c90a971b in address_space_write /softmmu/physmem.c:2891:18 +#9 0x5597c8d11eee in qtest_process_command /softmmu/qtest.c:539:13 +#10 0x5597c8d0eb97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#11 0x5597c955f286 in fd_chr_read /chardev/char-fd.c:68:9 +#12 0x7f994c124aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#13 0x5597c9bba363 in glib_pollfds_poll /util/main-loop.c:232:9 +#14 0x5597c9bba363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#15 0x5597c9bba363 in main_loop_wait /util/main-loop.c:531:11 +#16 0x5597c8c75599 in qemu_main_loop /softmmu/runstate.c:721:9 +#17 0x5597c6f021fd in main /softmmu/main.c:50:5 +#18 0x7f994bbc9cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#19 0x5597c6e55bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913914 b/results/classifier/gemma3:12b/device/1913914 new file mode 100644 index 000000000..c3e1338b0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913914 @@ -0,0 +1,60 @@ + +arm_gic: Abort in gic_clear_pending_sgi + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +write 0x8000000 0x1 0x02 +write 0x8010000 0x1 0x03 +write 0x8010004 0x1 0x10 +write 0x8000f2f 0x1 0x0 +writel 0x8000f00 0x2065559 +write 0x8000d56 0x1 0x0 +readl 0x801000b +EOF + +Stacktrace: +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../qemu/hw/intc/arm_gic.c:173:28 in +../qemu/hw/intc/arm_gic.c:173:28: runtime error: load of misaligned address 0x6290000215c1 for type 'uint32_t' (aka 'unsigned int'), which requires 16 byte alignment +0x6290000215c1: note: pointer points here + 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 1c 00 00 80 60 00 00 00 00 00 00 00 + ^ +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../qemu/hw/intc/arm_gic.c:173:28 in +[R +0.117623] readl 0x8010015 +[R +0.117718] readl 0x801000b +qemu-fuzz-aarch64: ../qemu/hw/intc/arm_gic.c:580: uint32_t gic_clear_pending_sgi(GICState *, int, int): Assertion `s->sgi_pending[irq][cpu] != 0' failed. +==762== ERROR: libFuzzer: deadly signal + #0 0x563d4e2371f1 in __sanitizer_print_stack_trace (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x350d1f1) + #1 0x563d4e182348 in fuzzer::PrintStackTrace() (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x3458348) + #2 0x563d4e167493 in fuzzer::Fuzzer::CrashCallback() (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x343d493) + #3 0x7feabe05350f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1350f) + #4 0x7feabde8e080 in __libc_signal_restore_set /build/glibc-suXNNi/glibc-2.29/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10 + #5 0x7feabde8e080 in raise /build/glibc-suXNNi/glibc-2.29/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #6 0x7feabde79534 in abort /build/glibc-suXNNi/glibc-2.29/stdlib/abort.c:79:7 + #7 0x7feabde7940e in __assert_fail_base /build/glibc-suXNNi/glibc-2.29/assert/assert.c:92:3 + #8 0x7feabde86b91 in __assert_fail /build/glibc-suXNNi/glibc-2.29/assert/assert.c:101:3 + #9 0x563d4eba2a3c in gic_clear_pending_sgi /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:580:9 + #10 0x563d4eba2a3c in gic_acknowledge_irq /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:630:19 + #11 0x563d4ebb4ca4 in gic_cpu_read /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:1615:17 + #12 0x563d4ebab538 in gic_thiscpu_read /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:1771:12 + #13 0x563d5029ec2d in memory_region_read_with_attrs_accessor /home/alxndr/build-asan/../qemu/softmmu/memory.c:464:9 + #14 0x563d502705f3 in access_with_adjusted_size /home/alxndr/build-asan/../qemu/softmmu/memory.c:552:18 + #15 0x563d5026eb44 in memory_region_dispatch_read1 /home/alxndr/build-asan/../qemu/softmmu/memory.c + #16 0x563d5026eb44 in memory_region_dispatch_read /home/alxndr/build-asan/../qemu/softmmu/memory.c:1449:9 + #17 0x563d5048c5bf in flatview_read_continue /home/alxndr/build-asan/../qemu/softmmu/physmem.c:2822:23 + #18 0x563d504a9a9b in address_space_read /home/alxndr/qemu/include/exec/memory.h:2484:26 + #19 0x563d504a9a9b in qtest_process_command /home/alxndr/build-asan/../qemu/softmmu/qtest.c:568:13 + #20 0x563d504a497f in qtest_process_inbuf /home/alxndr/build-asan/../qemu/softmmu/qtest.c:797:9 + #21 0x563d504a46d5 in qtest_server_inproc_recv /home/alxndr/build-asan/../qemu/softmmu/qtest.c:904:9 + #22 0x563d50ce5cc8 in qtest_sendf /home/alxndr/build-asan/../qemu/tests/qtest/libqtest.c:438:5 + #23 0x563d50ce73a3 in qtest_read /home/alxndr/build-asan/../qemu/tests/qtest/libqtest.c:1032:5 + #24 0x563d4e264499 in __wrap_qtest_readl /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/qtest_wrappers.c:138:16 + #25 0x563d4e26ee5b in op_read /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/generic_fuzz.c:432:13 + #26 0x563d4e26dc46 in generic_fuzz /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 + #27 0x563d4e261283 in LLVMFuzzerTestOneInput /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/fuzz.c:151:5 + #28 0x563d4e168b51 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x343eb51) + #29 0x563d4e1542c2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x342a2c2) + #30 0x563d4e159d76 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x342fd76) + #31 0x563d4e182a32 in main (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x3458a32) + #32 0x7feabde7abba in __libc_start_main /build/glibc-suXNNi/glibc-2.29/csu/../csu/libc-start.c:308:16 + #33 0x563d4e12e989 in _start (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x3404989) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913915 b/results/classifier/gemma3:12b/device/1913915 new file mode 100644 index 000000000..6a315d84e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913915 @@ -0,0 +1,51 @@ + +aarc64-virt: Null-ptr dereference through virtio_write_config + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +writel 0x8000f00 0x81818191 +write 0x4010008004 0x1 0x06 +EOF + +Stacktrace: +../hw/intc/arm_gic.c:1498:13: runtime error: index 401 out of bounds for type 'uint8_t [16][8]' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13 in +OK +[S +0.048579] OK +[R +0.048593] write 0x4010008004 0x1 0x06 +../softmmu/memory.c:834:35: runtime error: member access within null pointer of type 'MemoryRegionIoeventfd' (aka 'struct MemoryRegionIoeventfd') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../softmmu/memory.c:834:35 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==637204==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55b2560417c1 bp 0x7ffefc928270 sp 0x7ffefc928020 T0) +==637204==The signal is caused by a READ memory access. +==637204==Hint: address points to the zero page. + #0 0x55b2560417c1 in addrrange_shift /home/alxndr/Development/qemu/build/../softmmu/memory.c:80:44 + #1 0x55b2560417c1 in address_space_update_ioeventfds /home/alxndr/Development/qemu/build/../softmmu/memory.c:834:19 + #2 0x55b2560408c7 in memory_region_transaction_commit /home/alxndr/Development/qemu/build/../softmmu/memory.c:1100:17 + #3 0x55b25481e065 in pci_update_mappings /home/alxndr/Development/qemu/build/../hw/pci/pci.c:1363:13 + #4 0x55b25481cec7 in pci_default_write_config /home/alxndr/Development/qemu/build/../hw/pci/pci.c:1423:9 + #5 0x55b254806227 in virtio_write_config /home/alxndr/Development/qemu/build/../hw/virtio/virtio-pci.c:608:5 + #6 0x55b2551f6e65 in pci_host_config_write_common /home/alxndr/Development/qemu/build/../hw/pci/pci_host.c:83:5 + #7 0x55b2560481fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 + #8 0x55b256047bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #9 0x55b256047467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #10 0x55b2563d7ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #11 0x55b2563cd71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #12 0x55b2563cd71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #13 0x55b256039d35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 + #14 0x55b256032b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #15 0x55b256883286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #16 0x7f8d8faf5aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #17 0x55b256ede363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #18 0x55b256ede363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #19 0x55b256ede363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #20 0x55b255f99599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #21 0x55b2542261fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #22 0x7f8d8f59acc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #23 0x55b254179bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/build/../softmmu/memory.c:80:44 in addrrange_shift +==637204==ABORTING \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913917 b/results/classifier/gemma3:12b/device/1913917 new file mode 100644 index 000000000..6731a4fa0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913917 @@ -0,0 +1,35 @@ + +aarch64-virt: heap-use-after-free in gic_dist_writeb + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +writel 0x8000f00 0x5affaf +write 0x8000eff 0x1 0x0 +EOF + +Stacktrace: +../hw/intc/arm_gic.c:1419:17: runtime error: index 3068 out of bounds for type 'gic_irq_state [1020]' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1419:17 in +================================================================= +==641550==ERROR: AddressSanitizer: heap-use-after-free on address 0x629000023a85 at pc 0x55b5dfb0fbf8 bp 0x7fff95cb5870 sp 0x7fff95cb5868 +WRITE of size 1 at 0x629000023a85 thread T0 + #0 0x55b5dfb0fbf7 in gic_dist_writeb /home/alxndr/Development/qemu/build/../hw/intc/arm_gic.c:1419:17 + #1 0x55b5dfb061e2 in gic_dist_write /home/alxndr/Development/qemu/build/../hw/intc/arm_gic.c + #2 0x55b5e0809ef4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:511:12 + #3 0x55b5e0808bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #4 0x55b5e0808467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #5 0x55b5e0b98ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #6 0x55b5e0b8e71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #7 0x55b5e0b8e71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #8 0x55b5e07fad35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 + #9 0x55b5e07f3b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #10 0x55b5e1044286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #11 0x7fa997b30aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #12 0x55b5e169f363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #13 0x55b5e169f363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #14 0x55b5e169f363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #15 0x55b5e075a599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #16 0x55b5de9e71fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #17 0x7fa9975d5cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #18 0x55b5de93abc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913919 b/results/classifier/gemma3:12b/device/1913919 new file mode 100644 index 000000000..e953cbec6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913919 @@ -0,0 +1,64 @@ + +Heap-buffer-overflow in sdhci_write_dataport + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -qtest stdio \ +-machine raspi3b,accel=qtest -m 1G +write 0x3f30002c 0x1 0x25 +write 0x3f300004 0x1 0x01 +write 0x3f300006 0x1 0xc0 +write 0x3f30000c 0x1 0x22 +write 0x3f30000e 0x1 0x20 +write 0x3f30000f 0x1 0x0 +write 0x3f300000 0x1 0x48 +write 0x3f300003 0x1 0x0 +write 0x3f300005 0x1 0x14 +write 0x3f300007 0x1 0x10 +write 0x3f30000c 0x1 0x32 +write 0x3f30000f 0x1 0x0 +write 0x3f300001 0x1 0x00 +write 0x3f300002 0x1 0x30 +write 0x3f300003 0x1 0x3f +EOF + +Stacktrace: +==654080==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000017b80 at pc 0x562988348719 bp 0x7fffd26552d0 sp 0x7fffd26552c8 +WRITE of size 1 at 0x619000017b80 thread T0 + #0 0x562988348718 in sdhci_write_dataport /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:560:39 + #1 0x562988348718 in sdhci_write /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1172:13 + #2 0x5629890591fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 + #3 0x562989058bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #4 0x562989058467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #5 0x5629893e8ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #6 0x5629893de71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #7 0x5629893de71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #8 0x562988334d9c in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 + #9 0x562988334d9c in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 + #10 0x562988334d9c in dma_memory_write /home/alxndr/Development/qemu/include/sysemu/dma.h:163:12 + #11 0x562988334d9c in sdhci_sdma_transfer_multi_blocks /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:617:13 + #12 0x56298834427f in sdhci_write /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1129:17 + #13 0x5629890591fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 + #14 0x562989058bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #15 0x562989058467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #16 0x5629893e8ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #17 0x5629893de71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #18 0x5629893de71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #19 0x56298904ad35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 + #20 0x562989043b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #21 0x562989894286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #22 0x7f535645baae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #23 0x562989eef363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #24 0x562989eef363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #25 0x562989eef363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #26 0x562988faa599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #27 0x5629872371fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #28 0x7f5355f00cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #29 0x56298718abc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +0x619000017b80 is located 0 bytes to the right of 1024-byte region [0x619000017780,0x619000017b80) +allocated by thread T0 here: + #0 0x562987204db2 in calloc (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x33cadb2) + #1 0x7f5356461ae0 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ae0) + #2 0x56298834a187 in sdhci_sysbus_realize /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1469:5 + #3 0x56298987fe77 in device_set_realized /home/alxndr/Development/qemu/build/../hw/core/qdev.c:761:13 + #4 0x5629898153b5 in property_set_bool /home/alxndr/Development/qemu/build/../qom/object.c:2255:5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1913926 b/results/classifier/gemma3:12b/device/1913926 new file mode 100644 index 000000000..219d7250b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1913926 @@ -0,0 +1,30 @@ + +[QEMU User-Mode] Mesa Fails To Load RadeonSI Driver When In Docker Image + +# System Details +AMD Ryzen 7 3700U +Ubuntu 20.04 Focal Focus + +# Dockerfile + +FROM arm32v7/debian:bullseye + +RUN apt-get update && apt-get install -y mesa-utils + +ENTRYPOINT glxgears + +# Instructions For Reproduction +1. Install Docker +2. Build Docker Image: docker build --tag mesa-arm-test . +3. Run: docker run -v /tmp/.X11-unix:/tmp/.X11-unix --device /dev/dri:/dev/dri -e "DISPLAY=${DISPLAY}" mesa-arm-test + +The Output Is: + +amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-38) +amdgpu: amdgpu_device_initialize failed. +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +libGL error: failed to get magic +libGL error: failed to load driver: radeonsi + +It then appears to run using software rendering. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1914 b/results/classifier/gemma3:12b/device/1914 new file mode 100644 index 000000000..068a7f8aa --- /dev/null +++ b/results/classifier/gemma3:12b/device/1914 @@ -0,0 +1,8 @@ + +x86 q35 machine type documentation is missing +Description of problem: +The x86 machine type of q35 was added in 2012 by commit +df2d8b3ed4d2 ("q35: Introduce q35 pc based chipset emulator") +but no documentation was added to docs/master/system/target-i386.html +Additional information: +There was development documentation at https://wiki.qemu.org/Features/Q35 diff --git a/results/classifier/gemma3:12b/device/1914236 b/results/classifier/gemma3:12b/device/1914236 new file mode 100644 index 000000000..f3db422ac --- /dev/null +++ b/results/classifier/gemma3:12b/device/1914236 @@ -0,0 +1,98 @@ + +QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of mptsas1068 emulator + +* Cheolwoo Myung of Seoul National University reported a use-after-free issue in the SCSI Megaraid + emulator of the QEMU. + +* It occurs while handling mptsas_process_scsi_io_request(), as it does not + check a list in s->pending. + +* This was found in version 5.2.0 (master) + +==31872==ERROR: AddressSanitizer: heap-use-after-free on address +0x60c000107568 at pc 0x564514950c7c bp 0x7fff524ef4b0 sp 0x7fff524ef4a0 WRITE of size 8 at 0x60c000107568 thread T0 +#0 0x564514950c7b in mptsas_process_scsi_io_request ../hw/scsi/mptsas.c:306 +#1 0x564514950c7b in mptsas_fetch_request ../hw/scsi/mptsas.c:775 +#2 0x564514950c7b in mptsas_fetch_requests ../hw/scsi/mptsas.c:790 +#3 0x56451585c25d in aio_bh_poll ../util/async.c:164 +#4 0x5645158d7e7d in aio_dispatch ../util/aio-posix.c:381 +#5 0x56451585be2d in aio_ctx_dispatch ../util/async.c:306 +#6 0x7f1cc8af4416 in g_main_context_dispatch +(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c416) +#7 0x56451583f059 in glib_pollfds_poll ../util/main-loop.c:221 +#8 0x56451583f059 in os_host_main_loop_wait ../util/main-loop.c:244 +#9 0x56451583f059 in main_loop_wait ../util/main-loop.c:520 +#10 0x56451536b181 in qemu_main_loop ../softmmu/vl.c:1537 +#11 0x5645143ddd3d in main ../softmmu/main.c:50 +#12 0x7f1cc2650b96 in __libc_start_main +(/lib/x86_64-linux-gnu/libc.so.6+0x21b96) +#13 0x5645143eece9 in _start +(/home/cwmyung/prj/hyfuzz/src/qemu-repro/build/qemu-system-i386+0x1d55ce9) + +0x60c000107568 is located 104 bytes inside of 120-byte region +[0x60c000107500,0x60c000107578) +freed by thread T0 here: +#0 0x7f1cca9777a8 in __interceptor_free +(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) +#1 0x56451495008b in mptsas_process_scsi_io_request ../hw/scsi/mptsas.c:358 +#2 0x56451495008b in mptsas_fetch_request ../hw/scsi/mptsas.c:775 +#3 0x56451495008b in mptsas_fetch_requests ../hw/scsi/mptsas.c:790 +#4 0x7fff524ef8bf (<unknown module>) + +previously allocated by thread T0 here: +#0 0x7f1cca977d28 in __interceptor_calloc +(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) +#1 0x7f1cc8af9b10 in g_malloc0 +(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) +#2 0x7fff524ef8bf (<unknown module>) + +SUMMARY: AddressSanitizer: heap-use-after-free ../hw/scsi/mptsas.c:306 +in mptsas_process_scsi_io_request +Shadow bytes around the buggy address: +0x0c1880018e50: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd +0x0c1880018e60: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa +0x0c1880018e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +0x0c1880018e80: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd +0x0c1880018e90: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa +=>0x0c1880018ea0: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fa +0x0c1880018eb0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 +0x0c1880018ec0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa +0x0c1880018ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +0x0c1880018ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +0x0c1880018ef0: 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 +==31872==ABORTING + + +To reproduce this issue, please run the QEMU with the following command +line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the +following command line. +$ ./qemu-system-i386 -m 512 -drive +file=./hyfuzz.img,index=0,media=disk,format=raw -device +mptsas1068,id=scsi -device scsi-hd,drive=SysDisk -drive +id=SysDisk,if=none,file=./disk.img \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1914535 b/results/classifier/gemma3:12b/device/1914535 new file mode 100644 index 000000000..febe66ce7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1914535 @@ -0,0 +1,6 @@ + +PL110 8-bit mode is not emulated correctly + +When the emulated pl110/pl111 is switched programmatically to 8-bit color depth mode, the display is drawn green and blue, but the real PL110 displays grayscale in 8-bit mode. + +The bug appears in qemu-system-arm version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8) and qemu-system-arm version 5.2.50 (v5.2.0-1579-g99ae0cd90d). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1914638 b/results/classifier/gemma3:12b/device/1914638 new file mode 100644 index 000000000..356a104b8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1914638 @@ -0,0 +1,181 @@ + +[OSS-Fuzz] Issue 30219: Global-buffer-overflow in mode_sense_page + +== Reproducer (build with --enable-sanitizers) == + +cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +-device megasas -device scsi-cd,drive=null0 \ +-blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +-nographic -qtest stdio +outl 0xcf8 0x80000818 +outl 0xcfc 0xc000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +write 0x0 0x1 0x03 +write 0x7 0x1 0x3f +write 0x10 0x1 0x03 +write 0x20 0x1 0x55 +write 0x21 0x1 0x10 +write 0x28 0x1 0x10 +write 0x30 0x1 0xff +write 0x31 0x1 0xff +write 0x32 0x1 0xff +write 0x33 0x1 0xff +write 0x34 0x1 0xff +write 0x35 0x1 0xff +write 0x36 0x1 0xff +write 0x37 0x1 0xff +write 0x3b 0x1 0x10 +write 0x43 0x1 0x10 +write 0x44 0x1 0x10 +write 0x4f 0x1 0x10 +write 0x53 0x1 0x10 +write 0x5b 0x1 0x10 +write 0x5f 0x1 0x10 +write 0x67 0x1 0x10 +write 0x6b 0x1 0x10 +write 0x73 0x1 0x10 +write 0x75 0x1 0x10 +write 0x7d 0x1 0x10 +write 0x83 0x1 0x10 +write 0x8b 0x1 0x10 +write 0x8f 0x1 0x10 +write 0x97 0x1 0x10 +write 0x9b 0x1 0x10 +write 0xa3 0x1 0x03 +write 0xa6 0x1 0x10 +write 0xae 0x1 0x10 +write 0xb3 0x1 0x10 +write 0xbb 0x1 0x10 +write 0xbf 0x1 0x10 +write 0xc7 0x1 0x10 +write 0xca 0x1 0x10 +write 0xd3 0x1 0x06 +write 0xd7 0x1 0x10 +write 0xdf 0x1 0x10 +write 0xe3 0x1 0x06 +write 0xeb 0x1 0x01 +write 0xef 0x1 0x10 +write 0xf7 0x1 0x10 +write 0xfb 0x1 0x10 +write 0x103 0x1 0x20 +write 0x107 0x1 0x10 +write 0x10f 0x1 0x10 +write 0x113 0x1 0x10 +write 0x11b 0x1 0x10 +write 0x11f 0x1 0x10 +write 0x127 0x1 0x10 +write 0x12b 0x1 0x10 +write 0x130 0x1 0x10 +write 0x137 0x1 0x10 +write 0x13f 0x1 0x40 +write 0x141 0x1 0x10 +write 0x14b 0x1 0x10 +write 0x14f 0x1 0x10 +write 0x157 0x1 0x10 +write 0x15b 0x1 0x10 +write 0x161 0x1 0x10 +write 0x167 0x1 0x03 +write 0x16f 0x1 0x06 +write 0x172 0x1 0x10 +write 0x17b 0x1 0x10 +write 0x17f 0x1 0x10 +write 0x187 0x1 0x10 +write 0x18b 0x1 0x10 +write 0x192 0x1 0x10 +write 0x197 0x1 0x06 +write 0x19f 0x1 0x20 +write 0x1a3 0x1 0x10 +write 0x1ab 0x1 0x40 +write 0x1af 0x1 0x01 +write 0x1b7 0x1 0x10 +write 0x1bb 0x1 0x20 +write 0x1c3 0x1 0x10 +write 0x1c7 0x1 0x20 +write 0x1cc 0x1 0x10 +write 0x1d3 0x1 0x10 +write 0x1db 0x1 0x10 +write 0x1df 0x1 0x10 +write 0x1e7 0x1 0x10 +write 0x1eb 0x1 0x10 +write 0x1f3 0x1 0x10 +write 0x1f4 0x1 0x10 +write 0x1fd 0x1 0x10 +write 0x203 0x1 0x40 +write 0x20b 0x1 0x10 +write 0x20f 0x1 0x10 +write 0x217 0x1 0x10 +write 0x21b 0x1 0x10 +write 0x223 0x1 0x10 +write 0x225 0x1 0x10 +write 0x22e 0x1 0x10 +write 0x233 0x1 0x06 +write 0x23b 0x1 0x10 +write 0x23f 0x1 0x10 +write 0x247 0x1 0x10 +write 0x24b 0x1 0x10 +write 0x252 0x1 0x10 +write 0x256 0x1 0x10 +write 0x25f 0x1 0x10 +write 0x263 0x1 0x20 +write 0x26b 0x1 0x06 +write 0x26f 0x1 0x40 +write 0x277 0x1 0x10 +write 0x27b 0x1 0x10 +write 0x283 0x1 0x10 +write 0x287 0x1 0x10 +write 0x28f 0x1 0x10 +write 0x290 0x1 0x10 +write 0x29b 0x1 0x10 +write 0x29f 0x1 0x10 +write 0x2a7 0x1 0x10 +write 0x2ab 0x1 0x10 +write 0x2b3 0x1 0x10 +write 0x2b7 0x1 0x10 +write 0x2bf 0x1 0x10 +write 0x2c1 0x1 0x10 +write 0x2c9 0x1 0x10 +write 0x2cf 0x1 0x10 +write 0x2d7 0x1 0x10 +write 0x2db 0x1 0x10 +write 0x2e3 0x1 0x10 +write 0x2e7 0x1 0x10 +write 0x2ef 0x1 0x03 +write 0x2f2 0x1 0x10 +write 0x2fa 0x1 0x10 +write 0x2ff 0x1 0x10 +write 0x307 0x1 0x10 +write 0x30b 0x1 0x10 +write 0x313 0x1 0x10 +write 0x316 0x1 0x10 +write 0x31f 0x1 0x06 +write 0x323 0x1 0x10 +outb 0xc040 0x0 +EOF + +=== Stack Trace === +==1025760==ERROR: AddressSanitizer: global-buffer-overflow on address 0x558f557253fc at pc 0x558f549ab376 bp +0x7ffd436e9770 sp 0x7ffd436e9768 +READ of size 4 at 0x558f557253fc thread T0 +SCARINESS: 17 (4-byte-read-global-buffer-overflow) +#0 0x558f549ab375 in mode_sense_page /src/qemu/hw/scsi/scsi-disk.c:1104:10 +#1 0x558f549afd86 in scsi_disk_check_mode_select /src/qemu/hw/scsi/scsi-disk.c:1447:11 +#2 0x558f549af9a6 in mode_select_pages /src/qemu/hw/scsi/scsi-disk.c:1515:17 +#3 0x558f549ae593 in scsi_disk_emulate_mode_select /src/qemu/hw/scsi/scsi-disk.c:1570:13 +#4 0x558f549a56e9 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1861:9 +#5 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +#6 0x558f548b9fc4 in scsi_req_data /src/qemu/hw/scsi/scsi-bus.c:1427:5 +#7 0x558f549a5554 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1853:9 +#8 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +#9 0x558f54ac7cf6 in megasas_enqueue_req /src/qemu/hw/scsi/megasas.c:1660:9 +#10 0x558f54ab6e09 in megasas_handle_scsi /src/qemu/hw/scsi/megasas.c:1735:5 +#11 0x558f54ab3083 in megasas_handle_frame /src/qemu/hw/scsi/megasas.c:1974:24 +#12 0x558f54ab1c8b in megasas_mmio_write /src/qemu/hw/scsi/megasas.c:2131:9 +#13 0x558f54acc784 in megasas_port_write /src/qemu/hw/scsi/megasas.c:2182:5 +#14 0x558f54f78d57 in memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#15 0x558f54f78be2 in access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#16 0x558f54f78441 in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#17 0x558f550d5627 in flatview_write_continue /src/qemu/softmmu/physmem.c:2763:23 +#18 0x558f550d02ac in flatview_write /src/qemu/softmmu/physmem.c:2803:14 +#19 0x558f550d00c7 in address_space_write /src/qemu/softmmu/physmem.c:2895:18 +#20 0x558f5506c4ff in cpu_outb /src/qemu/softmmu/ioport.c:60:5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1915535 b/results/classifier/gemma3:12b/device/1915535 new file mode 100644 index 000000000..a09e11ee7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1915535 @@ -0,0 +1,69 @@ + +Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi + +Maybe this is a duplicate of https://bugs.launchpad.net/qemu/+bug/1906693 ... +In any case, ATAPI is probably a lot more common than megasas, so this might be a more useful reproducer + +==Reproducer== + +cat << EOF | ./qemu-system-i386 -display none \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-cd,drive=disk0 -machine accel=qtest -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0xe0000398 0x1 0x01 +write 0x63 0x1 0x06 +write 0x68 0x1 0x06 +write 0x69 0x1 0xf8 +write 0x6a 0x1 0xff +write 0xfff806 0x1 0x27 +write 0xfff807 0x1 0x80 +write 0xfff808 0x1 0x61 +write 0x1005734 0x1 0x3f +write 0x1005774 0x1 0x20 +write 0x1005784 0x1 0x34 +write 0x10057a4 0x1 0x27 +write 0x10057b4 0x1 0x3f +write 0x10057c3 0x1 0xce +write 0x10057d4 0x1 0x1a +write 0x10057e3 0x1 0xff +write 0x10057e4 0x1 0x3f +write 0x10057f4 0x1 0x38 +write 0x1005814 0x1 0x3e +write 0x1005823 0x1 0x60 +write 0x1005824 0x1 0x2d +write 0x1005833 0x1 0x74 +write 0x1005834 0x1 0x01 +write 0x1005863 0x1 0xff +write 0x1005883 0x1 0x5a +write 0x1005884 0x1 0x06 +write 0xe00003b8 0x1 0x08 +EOF + + +==Stack Trace== +i386: ahci: PRDT length for NCQ command (0x0) is smaller than the requested size (0x5a00) +qemu-fuzz-i386-target-generic-fuzz-ahci-atapi: ../block/io.c:1982: int +bdrv_co_write_req_prepare(BdrvChild *, int64_t, int64_t, BdrvTrackedRequest +*, int): Assertion `child->perm & BLK_PERM_WRITE' failed. +==279048== ERROR: libFuzzer: deadly signal +#0 0x560c92718f50 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/ubsan/ubsan_diag_standalone.cpp:33:3 +#1 0x560c926c2f98 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 +#2 0x560c926a7fd3 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 +#3 0x7ff7d707038f in libpthread.so.0 +#4 0x7ff7d66a8437 in raise +#5 0x7ff7d66aa039 in abort +#6 0x7ff7d66a0be6 in libc.so.6 +#7 0x7ff7d66a0c91 in __assert_fail +#8 0x560c92f4fc79 in bdrv_co_write_req_prepare /src/qemu/block/io.c:1982:13 +#9 0x560c92f4c974 in bdrv_aligned_pwritev /src/qemu/block/io.c:2065:11 +#10 0x560c92f4b937 in bdrv_co_pwritev_part /src/qemu/block/io.c:2270:11 +#11 0x560c92f392e7 in blk_do_pwritev_part /src/qemu/block/block-backend.c:1260:11 +#12 0x560c92f39a55 in blk_aio_write_entry /src/qemu/block/block-backend.c:1476:17 +#13 0x560c930d19d5 in coroutine_trampoline /src/qemu/util/coroutine-ucontext.c:173:9 +#14 0x7ff7d66bd5df in libc.so.6 + +OSS-Fuzz link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30857 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1915539 b/results/classifier/gemma3:12b/device/1915539 new file mode 100644 index 000000000..bd0f49434 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1915539 @@ -0,0 +1,95 @@ + +Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer + +== Reproducer == + +cat << EOF | ./qemu-system-i386 -display none \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-hd,drive=disk0 -machine accel=qtest -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0x10a 0x1 0x02 +write 0xe0000398 0x1 0x01 +write 0x20000 0x1 0x27 +write 0x20001 0x1 0x80 +write 0x20002 0x1 0x20 +write 0x20005 0x1 0x02 +write 0xe00003b8 0x2 0x0101 +write 0xe0000004 0x1 0x01 +write 0x2bb 0x1 0x00 +write 0x2bf 0x1 0x00 +write 0x2cf 0x1 0x00 +write 0x2db 0x1 0x00 +write 0x2df 0x1 0x00 +write 0x2ed 0x1 0x00 +write 0x2ef 0x1 0x00 +write 0x2fb 0x1 0x00 +write 0x2ff 0x1 0x00 +write 0x31f 0x1 0x00 +write 0x32b 0x1 0x00 +write 0x32f 0x1 0x00 +write 0x337 0x1 0x00 +write 0x33f 0x1 0x00 +write 0x347 0x1 0x00 +write 0x357 0x1 0x00 +write 0x35f 0x1 0x00 +write 0x36b 0x1 0x00 +write 0x36f 0x1 0x00 +write 0x377 0x1 0x00 +write 0x37f 0x1 0x00 +write 0x397 0x1 0x00 +write 0x39f 0x1 0x00 +write 0x3ab 0x1 0x00 +write 0x3af 0x1 0x00 +write 0x3b7 0x1 0x00 +write 0x3bf 0x1 0x00 +write 0x3c7 0x1 0x00 +write 0x3d7 0x1 0x00 +write 0x3df 0x1 0x00 +write 0x3eb 0x1 0x00 +write 0x3ef 0x1 0x00 +write 0x3f7 0x1 0x00 +write 0x3ff 0x1 0x00 +write 0xe0000394 0x1 0x00 +write 0xe0000398 0x1 0x01 +EOF + +== Stack Trace == +../hw/ide/ahci.c:1349:46: runtime error: member access within null pointer of +type 'AHCICmdHdr' (aka 'struct AHCICmdHdr') SUMMARY: +UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1349:46 in +../hw/ide/ahci.c:1349:46: runtime error: load of null pointer of type +'uint16_t' (aka 'unsigned short') +SUMMARY: UndefinedBehaviorSanitizer: +undefined-behavior ../hw/ide/ahci.c:1349:46 in AddressSanitizer:DEADLYSIGNAL +================================================================= +==238806==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc +0x555787d414c9 bp 0x7fffe1bb41a0 sp 0x7fffe1bb3fe0 T0) +==238806==The signal is caused by a READ memory access. +==238806==Hint: address points to the zero page. +#0 0x555787d414c9 in ahci_pio_transfer build/../hw/ide/ahci.c:1349:46 +#1 0x5557886089d6 in ide_transfer_start_norecurse build/../hw/ide/core.c:553:5 +#2 0x555788638945 in ide_transfer_start build/../hw/ide/core.c:560:9 +#3 0x555788638945 in ide_sector_read_cb build/../hw/ide/core.c:761:5 +#4 0x55578860c989 in ide_buffered_readv_cb build/../hw/ide/core.c:656:9 +#5 0x5557898999d6 in blk_aio_complete build/../block/block-backend.c:1412:9 +#6 0x555789db8d26 in aio_bh_poll build/../util/async.c:164:13 +#7 0x555789d80704 in aio_dispatch build/../util/aio-posix.c:381:5 +#8 0x555789dbd94c in aio_ctx_dispatch build/../util/async.c:306:5 +#9 0x7f6dcedcfbaa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa) +#10 0x555789dc3763 in glib_pollfds_poll build/../util/main-loop.c:232:9 +#11 0x555789dc3763 in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#12 0x555789dc3763 in main_loop_wait build/../util/main-loop.c:531:11 +#13 0x555789206a49 in qemu_main_loop build/../softmmu/runstate.c:722:9 +#14 0x555787d052ed in main build/../softmmu/main.c:50:5 +#15 0x7f6dcd84ecc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#16 0x555787c5b619 in _start (system-i386+0x2a13619) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV build/../hw/ide/ahci.c:1349:46 in ahci_pio_transfer +==238806==ABORTING + +OSS-Fuzz link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30861 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1916 b/results/classifier/gemma3:12b/device/1916 new file mode 100644 index 000000000..296497d5a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1916 @@ -0,0 +1,29 @@ + +qemu-fixed-text-console.device not found error when using display set to anything but SDL +Description of problem: +When attempting to launch QEmu from the command line using any display option aside from `sdl`, QEmu fails to launch with this error message: + +```plaintext +Unexpected error in object_property_find_err() at ../qom/object.c:1314: +qemu: Property 'qemu-fixed-text-console.device' not found +Aborted +``` + +This error is almost nonexistent when searching online. There is a mention of it in this chain of messages on the mailing list from about a week ago, but it doesn't seem to discuss any kind of way to remedy it. Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg988630.html + +I came across this issue because I was attempting to launch QEmu in other display modes, because for some reason if I launch with the `-display sdl` option, QEmu successfully starts up but then the display is black the majority of the time with some very brief flickers of the OS, and mouse/keyboard input don't seem to be correctly handled, making it unusable. So when trying to see if another display configuration could help me be able to resolve the black screen issue, I learned that I can't even launch with any other configuration due to the fixed text console not being found. + +I have been using these simple arguments for running the configure script: + +```plaintext +../configure --enable-debug --target-list=x86_64-softmmu +``` + +I tried using the configure flags `--enable-gtk` and `--enable-sdl` to see if they made any difference, but it seemed like they did not (neither the black screen issue or the fixed text console device error changed) so I just started leaving them off. +Steps to reproduce: +1. Run configure script +2. Run make to build QEmu +3. Launch QEmu using `-display gtk` or with no `-display` option specified at all (also tried: `./qemu-system-x86_64 -m 6G -smp 2 -hda ../../vdisk1.qcow2`) and the error occurred. +4. Error occurs +Additional information: +I am new to QEmu and am trying to use it as part of a college project, so if anyone wants to respond, please let me know if I can give any additional information at all that could help. diff --git a/results/classifier/gemma3:12b/device/1917394 b/results/classifier/gemma3:12b/device/1917394 new file mode 100644 index 000000000..919e4b2e3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1917394 @@ -0,0 +1,40 @@ + +command lspci does not show the IVSHMEM device + +qeum version: +QEMU emulator version 4.2.1 + +I met a problem when I tried to use IVSHMEM. Command lspci does not show the IVSHMEM device. +Below is the configuration from my side: + +1. guest vm xml configuration. + <shmem name='ivshmem'> + <model type='ivshmem-plain'/> + <size unit='M'>2</size> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> + </shmem> + +2. after the booting up and I found the qemu commandline ideedly have the device option: +ps aux | grep ivshmem + /usr/bin/qemu-system-x86_64 + .......(ignore other options) +-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 + +3. lspci command not shown the device. + +4. lshw command indeedly show the device: + +*-memory UNCLAIMED + description: RAM memory + product: Inter-VM shared memory + vendor: Red Hat, Inc. + physical id: 10 + bus info: pci@0000:00:10.0 + version: 01 + width: 64 bits + clock: 33MHz (30.3ns) + configuration: latency=0 + resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff + +My host and vm os is ubuntu 20.04 and version is: +#49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1917442 b/results/classifier/gemma3:12b/device/1917442 new file mode 100644 index 000000000..d73b8de95 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1917442 @@ -0,0 +1,77 @@ + +[AHCI] crash when running a GNU/Hurd guest + +QEMU git hash = 51db2d7cf2 + +Running guest OS using: + +$ gdb --args /extra/qemu/bin/qemu-system-i386 -M q35,accel=kvm -m 4096 -net user,hostfwd=tcp::8888-:22 -net nic -drive id=udisk,file=/dev/sdd,format=raw,if=none -device ide-drive,drive=udisk,bootindex=1 -curses + +... + +root@zamhurd:~# .ahcisata0 channel 5: setting WDCTL_RST failed for drive 0 + + +Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. + [Switching to Thread 0x7ffff4f7bf00 (LWP 590666)] +ahci_commit_buf (dma=0x555557335870, tx_bytes=2048) at ../hw/ide/ahci.c:1462 +1462 tx_bytes += le32_to_cpu(ad->cur_cmd->status); +(gdb) bt full +#0 ahci_commit_buf (dma=0x555557335870, tx_bytes=2048) + at ../hw/ide/ahci.c:1462 + ad = 0x555557335870 +#1 0x0000555555893171 in dma_buf_commit (s=0x555557335930, tx_bytes=2048) + at ../hw/ide/core.c:805 +#2 0x00005555558934f8 in ide_dma_cb (opaque=0x555557335930, ret=0) + at ../hw/ide/core.c:887 + s = 0x555557335930 + n = 4 + sector_num = 4491160 + offset = 140732794753312 + stay_active = false + prep_size = 0 + __PRETTY_FUNCTION__ = "ide_dma_cb" +#3 0x0000555555830720 in dma_complete (dbs=0x7ffee83d5120, ret=0) + at ../softmmu/dma-helpers.c:121 + __PRETTY_FUNCTION__ = "dma_complete" +#4 0x00005555558307cd in dma_blk_cb (opaque=0x7ffee83d5120, ret=0) + at ../softmmu/dma-helpers.c:139 + dbs = 0x7ffee83d5120 + cur_addr = 140732794753408 + cur_len = 93825013280880 + mem = 0x7ffeeccfef00 + __PRETTY_FUNCTION__ = "dma_blk_cb" +#5 0x0000555555d92bce in blk_aio_complete (acb=0x7ffee847bbe0) + at ../block/block-backend.c:1412 +#6 0x0000555555d92df0 in blk_aio_read_entry (opaque=0x7ffee847bbe0) + at ../block/block-backend.c:1466 + acb = 0x7ffee847bbe0 + rwco = 0x7ffee847bc08 + qiov = 0x7ffee83d5180 + __PRETTY_FUNCTION__ = "blk_aio_read_entry" +#7 0x0000555555e85580 in coroutine_trampoline (i0=-398117056, i1=32766) + at ../util/coroutine-ucontext.c:173 + arg = {p = 0x7ffee8453740, i = {-398117056, 32766}} + self = 0x7ffee8453740 + co = 0x7ffee8453740 + fake_stack_save = 0x0 +#8 0x00007ffff6544020 in __start_context () at /lib64/libc.so.6 +#9 0x00007ffeefdfd680 in () +#10 0x0000000000000000 in () +(gdb) +(gdb) l +1457 */ +1458 static void ahci_commit_buf(const IDEDMA *dma, uint32_t tx_bytes) +1459 { +1460 AHCIDevice *ad = DO_UPCAST(AHCIDevice, dma, dma); +1461 +1462 tx_bytes += le32_to_cpu(ad->cur_cmd->status); +1463 ad->cur_cmd->status = cpu_to_le32(tx_bytes); +1464 } +1465 +1466 static int ahci_dma_rw_buf(const IDEDMA *dma, bool is_write) +(gdb) p ad +$1 = (AHCIDevice *) 0x555557335870 +(gdb) p ad->cur_cmd +$2 = (AHCICmdHdr *) 0x0 +(gdb) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1918321 b/results/classifier/gemma3:12b/device/1918321 new file mode 100644 index 000000000..5322683f0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1918321 @@ -0,0 +1,84 @@ + +[OSS-Fuzz] Issue 31875 megasas: Null-ptr dereference in megasas_finish_dcmd + +Hello, + +== QTest Reproducer == +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ + * 512M -machine q35 -nodefaults -device megasas -device \ + * scsi-cd,drive=null0 -blockdev \ + * driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio + * outl 0xcf8 0x80000801 + * outl 0xcfc 0x05000000 + * outl 0xcf8 0x80000816 + * outl 0xcfc 0x19000000 + * write 0x1e1ed300 0x1 0x01 + * write 0x1e1ed307 0x1 0x01 + * write 0x1e1ed316 0x1 0x01 + * write 0x1e1ed328 0x1 0x01 + * write 0x1e1ed32f 0x1 0x01 + * outl 0x1940 0x1e1ed300 + * outl 0x19c0 0x00 + * EOF + */ +static void null_deref_megasas_finish_dcmd(void) +{ + QTestState *s = qtest_init( + "-display none , -m 512M -machine q35 -nodefaults -device megasas -device " + "scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 "); + qtest_outl(s, 0xcf8, 0x80000801); + qtest_outl(s, 0xcfc, 0x05000000); + qtest_outl(s, 0xcf8, 0x80000816); + qtest_outl(s, 0xcfc, 0x19000000); + qtest_bufwrite(s, 0x1e1ed300, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed307, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed316, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed328, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed32f, "\x01", 0x1); + qtest_outl(s, 0x1940, 0x1e1ed300); + qtest_outl(s, 0x19c0, 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, "i386") == 0) { + qtest_add_func("fuzz/null_deref_megasas_finish_dcmd", + null_deref_megasas_finish_dcmd); + } + + return g_test_run(); +} + +== Stack Trace == +../hw/scsi/megasas.c:1884:21: runtime error: member access within null pointer of type 'union mfi_frame' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:1884:21 in +../hw/scsi/megasas.c:1884:21: runtime error: member access within null pointer of type 'struct mfi_frame_header' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:1884:21 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==314546==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000003 (pc 0x55b1b4f4de73 bp 0x7ffcfc5a8bb0 sp 0x7ffcfc5a8900 T0) +==314546==The signal is caused by a WRITE memory access. +==314546==Hint: address points to the zero page. +#0 0x55b1b4f4de73 in megasas_command_complete build/../hw/scsi/megasas.c:1884:40 +#1 0x55b1b5613914 in scsi_req_complete build/../hw/scsi/scsi-bus.c:1515:5 +#2 0x55b1b5448aeb in scsi_dma_complete_noio build/../hw/scsi/scsi-disk.c:345:9 +#3 0x55b1b5446fc7 in scsi_dma_complete build/../hw/scsi/scsi-disk.c:366:5 +#4 0x55b1b4fffc56 in dma_complete build/../softmmu/dma-helpers.c:121:9 +#5 0x55b1b4fffc56 in dma_blk_cb build/../softmmu/dma-helpers.c:139:9 +#6 0x55b1b6856016 in blk_aio_complete build/../block/block-backend.c:1412:9 +#7 0x55b1b6f48b06 in aio_bh_poll build/../util/async.c:164:13 +#8 0x55b1b6f08cec in aio_dispatch build/../util/aio-posix.c:381:5 +#9 0x55b1b6f4d59c in aio_ctx_dispatch build/../util/async.c:306:5 +#10 0x7fd88c098baa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa) +#11 0x55b1b6f59a3c in glib_pollfds_poll build/../util/main-loop.c:232:9 +#12 0x55b1b6f59a3c in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#13 0x55b1b6f59a3c in main_loop_wait build/../util/main-loop.c:531:11 +#14 0x55b1b61a78a9 in qemu_main_loop build/../softmmu/runstate.c:725:9 +#15 0x55b1b4c751e5 in main build/../softmmu/main.c:50:5 +#16 0x7fd88aec6d09 in __libc_start_main csu/../csu/libc-start.c:308:16 +#17 0x55b1b4bc8bb9 in _start (system-i386+0x2b5fbb9) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1918917 b/results/classifier/gemma3:12b/device/1918917 new file mode 100644 index 000000000..23781ebea --- /dev/null +++ b/results/classifier/gemma3:12b/device/1918917 @@ -0,0 +1,75 @@ + +synchronous abort on accessing unused I/O ports on aarch64 + +version: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-6) +command line: qemu-system-aarch64 \ + -machine virt,virtualization=on,graphics=on,usb=on -cpu cortex-a57 -smp 2 -m 2G \ + -device virtio-blk-device,drive=hd0 \ + -drive if=none,format=raw,id=hd0,file=buildroot \ + -kernel arch/arm64/boot/Image \ + -nographic \ + -device virtio-rng-pci \ + -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic,model=virtio-net-pci \ + -append "root=/dev/vda earlyprintk=serial console=ttyAMA0 earlycon" + +I am observing "synchronous external abort" when kernel tries to access unused I/O ports (see below), while hardware/qemu should return 0xffffffff in this case. + +This is factored out of this LKML thread where Arnd describes it in more details: +https://lore.kernel<email address hidden>/ + +Internal error: synchronous external abort: 96000050 [#1] PREEMPT SMP +Dumping ftrace buffer: + (ftrace buffer empty) +Modules linked in: +CPU: 0 PID: 11231 Comm: syz-executor.1 Not tainted 5.12.0-rc2-syzkaller-00302-g28806e4d9b97 #0 +Hardware name: linux,dummy-virt (DT) +pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--) +pc : __raw_writeb arch/arm64/include/asm/io.h:27 [inline] +pc : _outb include/asm-generic/io.h:501 [inline] +pc : logic_outb+0x3c/0x114 lib/logic_pio.c:302 +lr : io_serial_out+0x80/0xc0 drivers/tty/serial/8250/8250_port.c:453 +sp : ffff000015f0f980 +x29: ffff000015f0f980 x28: ffff80001de0005d +x27: ffff80001601df00 x26: ffff000015f0fc90 +x25: ffff80001de00000 x24: ffff80001de00000 +x23: ffff00000e27f600 x22: 0000000000000000 +x21: 0000000000000002 x20: 0000000000000002 +x19: fffffbfffe800001 x18: ffff00006a678b48 +x17: 0000000000000000 x16: 0000000000000000 +x15: ffff8000197be810 x14: 1fffe00002be1f0e +x13: 1fffe00002be1e90 x12: ffff600002be1f39 +x11: 1fffe00002be1f38 x10: ffff600002be1f38 +x9 : dfff800000000000 x8 : 0000000000000003 +x7 : 0000000000000001 x6 : 0000000000000004 +x5 : ffff000015f0f9c0 x4 : dfff800000000000 +x3 : 0000000000000001 x2 : 1ffff00003494e6b +x1 : fffffbfffe800000 x0 : 0000000000ffbffe +Call trace: + _outb include/asm-generic/io.h:501 [inline] + logic_outb+0x3c/0x114 lib/logic_pio.c:302 + io_serial_out+0x80/0xc0 drivers/tty/serial/8250/8250_port.c:453 + serial_out drivers/tty/serial/8250/8250.h:118 [inline] + serial8250_set_THRI drivers/tty/serial/8250/8250.h:138 [inline] + __start_tx drivers/tty/serial/8250/8250_port.c:1566 [inline] + serial8250_start_tx+0x338/0x6c0 drivers/tty/serial/8250/8250_port.c:1666 + __uart_start.isra.0+0x10c/0x154 drivers/tty/serial/serial_core.c:127 + uart_start+0xe0/0x210 drivers/tty/serial/serial_core.c:137 + uart_flush_chars+0x10/0x20 drivers/tty/serial/serial_core.c:573 + __receive_buf drivers/tty/n_tty.c:1646 [inline] + n_tty_receive_buf_common+0x588/0x22c0 drivers/tty/n_tty.c:1739 + n_tty_receive_buf+0x14/0x20 drivers/tty/n_tty.c:1768 + tiocsti drivers/tty/tty_io.c:2317 [inline] + tty_ioctl+0xed0/0x1aec drivers/tty/tty_io.c:2718 + vfs_ioctl fs/ioctl.c:48 [inline] + __do_sys_ioctl fs/ioctl.c:753 [inline] + __se_sys_ioctl fs/ioctl.c:739 [inline] + __arm64_sys_ioctl+0x120/0x18c fs/ioctl.c:739 + __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] + invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] + el0_svc_common.constprop.0+0xf0/0x2c0 arch/arm64/kernel/syscall.c:129 + do_el0_svc+0xa4/0xd0 arch/arm64/kernel/syscall.c:168 + el0_svc+0x24/0x34 arch/arm64/kernel/entry-common.c:416 + el0_sync_handler+0x1a4/0x1b0 arch/arm64/kernel/entry-common.c:432 + el0_sync+0x170/0x180 arch/arm64/kernel/entry.S:699 +Code: d2bfd001 f2df7fe1 f2ffffe1 8b010273 (39000274) +---[ end trace 79cb47219936c254 ]--- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1919021 b/results/classifier/gemma3:12b/device/1919021 new file mode 100644 index 000000000..9f0f748af --- /dev/null +++ b/results/classifier/gemma3:12b/device/1919021 @@ -0,0 +1,9 @@ + +Confuse error message in virtio_init_region_cache() + +The error message added in commit e45da653223 to virtio_init_region_cache() +are somehow confuse: + + qemu-system-i386: Cannot map used + +It would be helpful to more explicit string, including "virtio" prefix. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1919035 b/results/classifier/gemma3:12b/device/1919035 new file mode 100644 index 000000000..ae65c6541 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1919035 @@ -0,0 +1,55 @@ + +Assertion failure in fifo8_pop_buf() through am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master, 3f8d1885e4) + + +``` +qemu-system-i386: ../util/fifo8.c:73: fifo8_pop_buf: Assertion `max > 0 && max <= fifo->num' failed. + +#0 0x00007ffff0218fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007ffff021a921 in __GI_abort () at abort.c:79 +#2 0x00007ffff020a48a in __assert_fail_base (fmt=0x7ffff0391750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555558ed24a0 "max > 0 && max <= fifo->num", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x49, function=function@entry=0x555558ed24e0 <__PRETTY_FUNCTION__.16603> "fifo8_pop_buf") at assert.c:92 +#3 0x00007ffff020a502 in __GI___assert_fail (assertion=assertion@entry=0x555558ed24a0 "max > 0 && max <= fifo->num", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x49, function=function@entry=0x555558ed24e0 <__PRETTY_FUNCTION__.16603> "fifo8_pop_buf") at assert.c:101 +#4 0x000055555877519a in fifo8_pop_buf (fifo=fifo@entry=0x61f000005200, max=max@entry=0xff, num=num@entry=0x7fff72bfa550) at ../util/fifo8.c:73 +#5 0x00005555572b7d9a in do_cmd (s=s@entry=0x61f000005088) at ../hw/scsi/esp.c:328 +#6 0x00005555572b879a in esp_do_nodma (s=s@entry=0x61f000005088) at ../hw/scsi/esp.c:701 +#7 0x00005555572bfd79 in handle_ti (s=0x61f000005088) at ../hw/scsi/esp.c:848 +#8 0x00005555572c419c in esp_reg_write (s=0x61f000005088, saddr=saddr@entry=0x3, val=<optimized out>) at ../hw/scsi/esp.c:987 +#9 0x0000555557bb916a in esp_pci_io_write (opaque=0x61f000004680, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at ../hw/scsi/esp-pci.c:214 +#10 0x000055555817ea28 in memory_region_write_accessor (mr=0x61f000004f70, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:491 +#11 0x0000555558176671 in access_with_adjusted_size (addr=addr@entry=0xc, value=value@entry=0x7fff72bfb2a8, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn= + 0x55555817e7c0 <memory_region_write_accessor>, mr=0x61f000004f70, attrs=...) at ../softmmu/memory.c:552 +#12 0x00005555581892aa in memory_region_dispatch_write (mr=mr@entry=0x61f000004f70, addr=<optimized out>, data=<optimized out>, data@entry=0x10, op=op@entry=MO_8, attrs=..., attrs@entry=...) at ../softmmu/memory.c:1508 +#13 0x0000555558024b66 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=<optimized out>, attrs=..., result=0x0) at /home/cwmyung/prj/hyfuzz/src/qemu-master/memory_ldst.c.inc:382 +#14 0x00007fff93236d3c in code_gen_buffer () +#15 0x0000555557e793bb in cpu_tb_exec (tb_exit=<optimized out>, itb=<optimized out>, cpu=0x62e0000004b4) at ../accel/tcg/cpu-exec.c:190 +#16 0x0000555557e793bb in cpu_loop_exec_tb (tb_exit=<optimized out>, last_tb=<optimized out>, tb=<optimized out>, cpu=0x62e0000004b4) at ../accel/tcg/cpu-exec.c:673 +#17 0x0000555557e793bb in cpu_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/cpu-exec.c:798 +#18 0x0000555557f5fc5a in tcg_cpus_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops.c:68 +#19 0x00005555582260af in mttcg_cpu_thread_fn (arg=arg@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 +#20 0x0000555558777b05 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#21 0x00007ffff05d26db in start_thread (arg=0x7fff72bff700) at pthread_create.c:463 +#22 0x00007ffff02fb71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` + + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +``` + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1919036 b/results/classifier/gemma3:12b/device/1919036 new file mode 100644 index 000000000..4773e90ba --- /dev/null +++ b/results/classifier/gemma3:12b/device/1919036 @@ -0,0 +1,57 @@ + +Assertion failure in fifo8_push_all() through am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master, 3f8d1885e4) + + +``` +qemu-system-i386: ../util/fifo8.c:43: fifo8_push_all: Assertion `fifo->num + num <= fifo->capacity' failed. + +#0 0x00007ffff0218fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007ffff021a921 in __GI_abort () at abort.c:79 +#2 0x00007ffff020a48a in __assert_fail_base (fmt=0x7ffff0391750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555558ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x555558ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") + at assert.c:92 +#3 0x00007ffff020a502 in __GI___assert_fail (assertion=assertion@entry=0x555558ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x555558ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") at assert.c:101 +#4 0x00005555587749c4 in fifo8_push_all (fifo=fifo@entry=0x61f000005200, data=data@entry=0x7fff72bfa640 "", num=num@entry=0x24) at ../util/fifo8.c:43 +#5 0x00005555572bd13e in esp_do_dma (s=s@entry=0x61f000005088) at ../hw/scsi/esp.c:577 +#6 0x00005555572bfc8f in handle_ti (s=0x61f000005088) at ../hw/scsi/esp.c:845 +#7 0x00005555572c419c in esp_reg_write (s=0x61f000005088, saddr=saddr@entry=0x3, val=<optimized out>) + at ../hw/scsi/esp.c:987 +#8 0x0000555557bb916a in esp_pci_io_write (opaque=0x61f000004680, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at ../hw/scsi/esp-pci.c:214 +#9 0x000055555817ea28 in memory_region_write_accessor (mr=0x61f000004f70, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:491 +#10 0x0000555558176671 in access_with_adjusted_size (addr=addr@entry=0xc, value=value@entry=0x7fff72bfb2a8, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn= + 0x55555817e7c0 <memory_region_write_accessor>, mr=0x61f000004f70, attrs=...) at ../softmmu/memory.c:552 +#11 0x00005555581892aa in memory_region_dispatch_write (mr=mr@entry=0x61f000004f70, addr=<optimized out>, data=<optimized out>, data@entry=0xffffff90, op=op@entry=MO_8, attrs=..., attrs@entry=...) at ../softmmu/memory.c:1508 +#12 0x0000555558024b66 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=<optimized out>, attrs=..., result=0x0) at /home/cwmyung/prj/hyfuzz/src/qemu-master/memory_ldst.c.inc:382 +#13 0x00007fff9323641c in code_gen_buffer () +#14 0x0000555557e793bb in cpu_tb_exec (tb_exit=<optimized out>, itb=<optimized out>, cpu=0x62e0000004b4) + at ../accel/tcg/cpu-exec.c:190 +#15 0x0000555557e793bb in cpu_loop_exec_tb (tb_exit=<optimized out>, last_tb=<optimized out>, tb=<optimized out>, cpu=0x62e0000004b4) at ../accel/tcg/cpu-exec.c:673 +#16 0x0000555557e793bb in cpu_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/cpu-exec.c:798 +#17 0x0000555557f5fc5a in tcg_cpus_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops.c:68 +#18 0x00005555582260af in mttcg_cpu_thread_fn (arg=arg@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 +#19 0x0000555558777b05 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#20 0x00007ffff05d26db in start_thread (arg=0x7fff72bff700) at pthread_create.c:463 +#21 0x00007ffff02fb71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` + + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +``` + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1920013 b/results/classifier/gemma3:12b/device/1920013 new file mode 100644 index 000000000..6ce87a40c --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1922252 b/results/classifier/gemma3:12b/device/1922252 new file mode 100644 index 000000000..876c4bc0e --- /dev/null +++ b/results/classifier/gemma3:12b/device/1922252 @@ -0,0 +1,8 @@ + +[feature request] webcam support + +Please + +I am impatient to get something as "-device usb-webcam" to share dynamically the webcam between host and guest. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1922325 b/results/classifier/gemma3:12b/device/1922325 new file mode 100644 index 000000000..74cd68791 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1922325 @@ -0,0 +1,24 @@ + +s390x-virtio-gpu-ccw module unnecessary? + +Hi + +Test building latest 6.0.0 release candidate on x86_64 host. A new module has appeared: + +/usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so + +Unless I'm missing something obvious, it would appear to be only useful on s390x platform. + +Why would I need this? For me it doesn't seem to do much: + +$ nm -D /usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so + w __cxa_finalize + w __gmon_start__ + w _ITM_deregisterTMCloneTable + w _ITM_registerTMCloneTable +00000000000010f0 T qemu_module_dummy +0000000000001100 T qemu_stamp_0d4aa0592256528f9885a56f182883665e60f8ec + +Bug or ... ? + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1922391 b/results/classifier/gemma3:12b/device/1922391 new file mode 100644 index 000000000..c2166c5a1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1922391 @@ -0,0 +1,57 @@ + +qemu-system-ppc assertion "!mr->container" failed + +Hi, + +I'm trying to run the NetBSD/macppc 8.2 installer (which is 32-bit ppc) in qemu-system-ppc +version 5.2.0, and I'm hitting this assertion failure quite a bit into the "unpacking sets" +part of the installation procedure, unpacking from the install iso image. + +Qemu is run on a NetBSD/amd64 9.1 host system. The stack backtrace from the core file is + +Program terminated with signal SIGABRT, Aborted. +#0 0x000078859a36791a in _lwp_kill () from /usr/lib/libc.so.12 +[Current thread is 1 (process 1)] +(gdb) where +#0 0x000078859a36791a in _lwp_kill () from /usr/lib/libc.so.12 +#1 0x000078859a3671ca in abort () from /usr/lib/libc.so.12 +#2 0x000078859a2a8507 in __assert13 () from /usr/lib/libc.so.12 +#3 0x000000015a3c19c0 in memory_region_finalize () +#4 0x000000015a3fef1c in object_unref () +#5 0x000000015a3feee6 in object_unref () +#6 0x000000015a374154 in address_space_unmap () +#7 0x000000015a276551 in pmac_ide_atapi_transfer_cb () +#8 0x000000015a150a59 in dma_blk_cb () +#9 0x000000015a46a1c7 in blk_aio_complete () +#10 0x000000015a5a617d in coroutine_trampoline () +#11 0x000078859a264150 in ?? () from /usr/lib/libc.so.12 +Backtrace stopped: Cannot access memory at address 0x7884894ff000 +(gdb) + +I start qemu with this small script: + +--- +#!/bin/sh + +MEM=3g +qemu-system-ppc \ + -M mac99,via=pmu \ + -m $MEM \ + -nographic \ + -drive id=hda,format=raw,file=disk.img \ + -L pc-bios \ + -netdev user,id=net0,hostfwd=tcp::2223-:22,ipv6=off \ + -net nic,model=rtl8139,netdev=net0 \ + -boot d \ + -cdrom NetBSD-8.2-macppc.iso +--- + +and boot the install kernel with "boot cd:ofwboot.xcf". If someone wants +to replicate this I can provide more detailed instructions to repeat the +procedure I used to start the install. + +Any hints about what more to look for? + +Regards, + +- Håvard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1922430 b/results/classifier/gemma3:12b/device/1922430 new file mode 100644 index 000000000..461175cc8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1922430 @@ -0,0 +1,35 @@ + +3d accel does not take care of 1280x960 setting + +openSuse 15.2 +kde plasma 5.21.3, frameworks 5.80.0 +libvirt 7.0.0 +qemu 5.2.0 +virgl renderer 0.8.2 + +here is my invocation + +qemu-kvm -enable-kvm \ +-m 2048 -smp 2 -cpu host \ +-device virtio-vga,virgl=on -display gtk,gl=on \ +-device usb-ehci \ +-device usb-kbd \ +-device usb-mouse \ +-device usb-tablet \ +-device ich9-intel-hda \ +-device hda-duplex,audiodev=snd0 \ +-audiodev pa,id=snd0 \ +-device usb-host,vendorid=0x046d,productid=0x08e5 \ +-boot menu=on \ +-nic bridge \ +~/QEMU_VM/android_x86_7.1-r5.img \ + +in the kernel command there is "vga=1280x960" + +with "-device qxl" no problem. I get immediately a window of size 1280x960. + +with "-device virtio-vga,virgl=on -display gtk,gl=on" + +i get a tiny window. + +i must uncheck "zoom to fit" to get a window of size 1280x960. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1923629 b/results/classifier/gemma3:12b/device/1923629 new file mode 100644 index 000000000..ab13174b3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1923629 @@ -0,0 +1,14 @@ + +RISC-V Vector Instruction vssub.vv not saturating + +I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF). + +Here is the bit of the code: + + vmv.v.i v16, 0 + … +8f040457 vssub.vv v8,v16,v8 + +I believe the instruction encoding is correct (vssub.vv with vd = v8, vs2 = v16, rs1 = v8), but the result does not saturate in QEMU. + +I’ve just tested with what I think is the latest branch ( https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still exists. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1923861 b/results/classifier/gemma3:12b/device/1923861 new file mode 100644 index 000000000..7e79c8ed9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1923861 @@ -0,0 +1,22 @@ + +Hardfault when accessing FPSCR register + +QEMU release version: v6.0.0-rc2 + +command line: +qemu-system-arm -machine mps3-an547 -nographic -kernel <my_project>.elf -semihosting -semihosting-config enable=on,target=native + +host operating system: Linux ISCNR90TMR1S 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +guest operating system: none (bare metal) + +Observation: +I am simulating embedded firmware for a Cortex-M55 device, using MPS3-AN547 machine. In the startup code I am accessing the FPSCR core register: + + unsigned int fpscr =__get_FPSCR(); + fpscr = fpscr & (~FPU_FPDSCR_AHP_Msk); + __set_FPSCR(fpscr); + +where the register access functions __get_FPSCR() and __set_FPSCR(fpscr) are taken from CMSIS_5 at ./CMSIS/Core/include/cmsis_gcc.h + +I observe hardfaults upon __get_FPSCR() and __set_FPSCR(fpscr). The same startup code works fine on the Arm Corstone-300 FVP. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1924738 b/results/classifier/gemma3:12b/device/1924738 new file mode 100644 index 000000000..03e9ba15f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1924738 @@ -0,0 +1,27 @@ + +Failed to restore domain - error load load virtio-balloon:virtio + +I noticed a domain restore error on my virtual machines. +I can't reproduce the error on a test virtual machine. + +sudo virsh save linux2020 /var/lib/libvirt/qemu/save/linux2020.save +Domain 'linux2020' saved to /var/lib/libvirt/qemu/save/linux2020.save + +sudo virsh restore /var/lib/libvirt/qemu/save/linux2020.save +error: Failed to restore domain from /var/lib/libvirt/qemu/save/linux2020.save +error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'server' deprecated +Please use server=on instead +qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'nowait' deprecated +Please use wait=off instead +qemu-system-x86_64: -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on: warning: short-form boolean option 'disable-ticketing' deprecated +Please use disable-ticketing=on instead +2021-04-16T09:47:15.037700Z qemu-system-x86_64: VQ 0 size 0x80 < last_avail_idx 0x0 - used_idx 0xcccc +2021-04-16T09:47:15.037737Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2021-04-16T09:47:15.037744Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-balloon' +2021-04-16T09:47:15.037849Z qemu-system-x86_64: load of migration failed: Operation not permitted + +If in the machine configuration replace +<type arch="x86_64" machine="pc-i440fx-5.1">hvm</type> +to +<type arch="x86_64" machine="pc-i440fx-5.0">hvm</type> +the virtual machine is recovering normally \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1924912 b/results/classifier/gemma3:12b/device/1924912 new file mode 100644 index 000000000..7032d593d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1924914 b/results/classifier/gemma3:12b/device/1924914 new file mode 100644 index 000000000..c42480da8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1924914 @@ -0,0 +1,14 @@ + +Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver) + +System is Arch Linux (guest and host OS). + +Problem: + +Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. + +This is the command I use to run my guest: + +qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 + +This doesn't happen when I use X with i3-wm. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1925 b/results/classifier/gemma3:12b/device/1925 new file mode 100644 index 000000000..536873e1b --- /dev/null +++ b/results/classifier/gemma3:12b/device/1925 @@ -0,0 +1,12 @@ + +RISC-V 64 System Emulator fdt imporperly created after machine init is done +Description of problem: +In commit 49554856 the creation of FDT is moved to `virt_machine_done()` +However, adding guest loader device requires the presence of fdt at `hw/core/guest-loader.c:50` when the fdt ptr is still 0x0. +Thus adding of guest loader device will fail. +Steps to reproduce: +1. Compile Qemu with riscv64 system emulator target +2. Compile Xen hypervisor platform (not necessary) +3. Instruct Qemu start with virt machine and any valid guest-loader device specification. +Additional information: +Commit that changes order of fdt creation: 49554856f0b6f622ab6afdcc275d4ab2ecb3625c diff --git a/results/classifier/gemma3:12b/device/1925094 b/results/classifier/gemma3:12b/device/1925094 new file mode 100644 index 000000000..c389968a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1925094 @@ -0,0 +1,6 @@ + +DISCARD support for Crypto Block Devices + +It appears that running `fstrim` or similar is useless when the VM is on a LUKS-encrypted device using QEMU's native LUKS support. + +Looking at the source, it seems that block/crypto.c lacks an implementation for bdrv_co_pdiscard, which probably needs to delegate to a per-crypto type discard helper. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1925109 b/results/classifier/gemma3:12b/device/1925109 new file mode 100644 index 000000000..3c63a8844 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1925496 b/results/classifier/gemma3:12b/device/1925496 new file mode 100644 index 000000000..9c2e8616c --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1926 b/results/classifier/gemma3:12b/device/1926 new file mode 100644 index 000000000..82a83dbcf --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/1926231 b/results/classifier/gemma3:12b/device/1926231 new file mode 100644 index 000000000..e05b65fe7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1926231 @@ -0,0 +1,38 @@ + +SCSI passthrough of SATA cdrom -> errors & performance issues + +qemu 5.0, compiled from git + +I am passing through a SATA cdrom via SCSI passthrough, with this libvirt XML: + + <hostdev mode='subsystem' type='scsi' managed='no' sgio='unfiltered' rawio='yes'> + <source> + <adapter name='scsi_host3'/> + <address bus='0' target='0' unit='0'/> + </source> + <alias name='hostdev0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </hostdev> + +It seems to mostly work, I have written discs with it, except I am getting errors that cause reads to take about 5x as long as they should, under certain circumstances. It appears to be based on the guest's read block size. + +I found that if on the guest I run, say `dd if=$some_large_file bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much is being read by a factor of about 2. Also many kernel messages like this happen on the guest: + +[ 190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s +[ 190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command [current] +[ 190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated +[ 190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00 00 80 00 +[ 190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 + +If I change to bs=131072 the errors stop and performance is normal. + +(262144 happens to be the block size ultimately used by md5sum, which is how I got here) + +I also ran strace on the qemu process while it was happening, and noticed SG_IO calls like this: + +21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0, dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +[etc] + +I suspect qemu is the culprit because I have tried a 4.19 guest kernel as well as a 5.9 one, with the same result. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1927408 b/results/classifier/gemma3:12b/device/1927408 new file mode 100644 index 000000000..7c8efa815 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1927408 @@ -0,0 +1,49 @@ + +USB Ethernet device (RNDIS) does not work on several tested operating systems + +The USB ethernet device does not work on most versions of operating systems I have tested. For each operating system the command to use this device was: -netdev user,id=mynet1 -device usb-net,netdev=mynet1. + + +Windows 2000 (qemu-system-i386): +- failed to load a driver for the device + + +Windows 7 (qemu-system-x86_64): +- Did not find a driver +- Followed the directions here: https://developer.toradex.com/knowledge-base/how-to-install-microsoft-rndis-driver-for-windows-7 +-- The device failed to start with error 10. +- Did see this message in the terminal on the host: +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa + + +Mac OS 10.4.11 (qemu-system-ppc): +- It actually works. +- did see these messages in the terminal on the host: +usbnet: failed control transaction: request 0x2143 value 0x1c index 0x0 length 0x0 +usbnet: failed control transaction: request 0x2143 value 0x1e index 0x0 length 0x0 + + +Mac OS 10.8.5 (qemu-system-x86_64): +- Fails to obtain IP address using DHCP. +- The Network pane does say the device is connected. +- A self-assigned IP address is given: 169.254.186.53. +-- It still did not work +- Did see this message in the terminal of the host: +usbnet: failed control transaction: request 0x2143 value 0x1c index 0x0 length 0x0 +usbnet: failed control transaction: request 0x2143 value 0x1e index 0x0 length 0x0 + + +Mac OS 10.2.3 (qemu-system-ppc): +- Did not appear to detect the USB NIC. Did not see it in the network pane. +- Apple System Profiler does see this device. +- Saw this message in there terminal of the host: qemu-system-ppc: Slirp: Failed to send packet, ret: -1 + + +Mac OS 9.2 (qemu-system-ppc): +- Apple System Profiler does show the device connected. +- The Tcp/ip control panel did not detect this device. + + +My guess is this device is buggy. If anyone has any tips or suggestions please let me know. + +Thank you. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/1929710 b/results/classifier/gemma3:12b/device/1929710 new file mode 100644 index 000000000..46915a222 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1929710 @@ -0,0 +1,156 @@ + +virDomainGetBlockJobInfo fails during swap_volume as disk '$disk' not found in domain + +Description +=========== + +The error handling around swap_volume is missing the following failure when calling virDomainGetBlockJobInfo() after the entire device is detached by QEMU (?) after it encounters a job during the block copy job that at first pauses and then somehow resumes the job: + +https://8a5fc27780098c5ee1bc-3ac81d180a9c011938b2cbb0293272f3.ssl.cf5.rackcdn.com/790660/5/gate/nova-next/e915ed4/controller/logs/screen-n-cpu.txt + +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver [None req-7cfcd661-29d4-4cc3-bc54-db0e7fed1a6e tempest-TestVolumeSwap-1841575704 tempest-TestVolumeSwap-1841575704-project-admin] Failure rebasing volume /dev/sdb on vdb.: libvirt.libvirtError: invalid argument: disk 'vdb' not found in domain +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver Traceback (most recent call last): +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2107, in _swap_volume +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver while not dev.is_job_complete(): +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 800, in is_job_complete +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver status = self.get_job_info() +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 707, in get_job_info +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver status = self._guest._domain.blockJobInfo(self._disk, flags=0) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 190, in doit +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver result = proxy_call(self._autowrap, f, *args, **kwargs) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 148, in proxy_call +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver rv = execute(f, *args, **kwargs) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 129, in execute +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver six.reraise(c, e, tb) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/six.py", line 719, in reraise +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver raise value +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/eventlet/tpool.py", line 83, in tworker +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver rv = meth(*args, **kwargs) +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python3.8/dist-packages/libvirt.py", line 985, in blockJobInfo +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver raise libvirtError('virDomainGetBlockJobInfo() failed') +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver libvirt.libvirtError: invalid argument: disk 'vdb' not found in domain +May 26 09:49:47.314813 ubuntu-focal-vexxhost-ca-ymq-1-0024823853 nova-compute[114649]: ERROR nova.virt.libvirt.driver + +https://zuul.opendev.org/t/openstack/build/e915ed4aeb9346bba83910bd79e9502b/log/controller/logs/libvirt/libvirtd_log.txt + +2021-05-26 09:49:40.189+0000: 79419: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7fc4bc07e7d0 msg={"execute":"blockdev-add","arguments":{"node-name":"libvirt-4-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-4-storage"},"id":"libvirt-375"}^M + +2021-05-26 09:49:46.154+0000: 79422: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7fc4bc07e7d0 msg={"execute":"blockdev-add","arguments":{"node-name":"libvirt-5-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-5-storage"},"id":"libvirt-379"}^M + +2021-05-26 09:49:46.165+0000: 79422: debug : qemuMonitorBlockdevMirror:3112 : jobname=copy-vdb-libvirt-4-format, persistjob=1, device=libvirt-4-format, target=libvirt-5-format, bandwidth=0, granularity=0, buf_size=0, shallow=0 + +2021-05-26 09:49:46.167+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'created'(1) + +2021-05-26 09:49:46.167+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'running'(2) + +2021-05-26 09:49:46.763+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'paused'(3) + +2021-05-26 09:49:46.763+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'running'(2) + +2021-05-26 09:49:46.841+0000: 79417: debug : qemuProcessHandleDeviceDeleted:1362 : Device virtio-disk1 removed from domain 0x7fc4b416b0e0 instance-0000000b + +2021-05-26 09:49:47.457+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'aborting'(8) + +2021-05-26 09:49:47.458+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'concluded'(9) + +2021-05-26 09:49:47.459+0000: 79417: debug : qemuProcessHandleJobStatusChange:1002 : job 'copy-vdb-libvirt-4-format'(domain: 0x7fc4b416b0e0,instance-0000000b) state changed to 'null'(11) + + +Steps to reproduce +================== + +$ cat queries/virDomainGetBlockJobInfo.yaml +query: > + message:"virDomainGetBlockJobInfo() failed" AND + tags:"screen-n-cpu.txt" + +$ elastic-recheck-query queries/virDomainGetBlockJobInfo.yaml +total hits: 6 +build_branch + 100% master +build_change + 50% 786588 + 50% 792322 +build_hostids + 50% 1b47a855be51bba01ac6d5e6fdc4859bc17ebe2c8faaeb83392f8ff3 79fb0487675c0137b7ac30f24b5de71c70afb836e46746de770fa0c0 + 50% 33381c047c348ffefebf6b10cb7f0473c2359757d0bf11cc101eec54 33381c047c348ffefebf6b10cb7f0473c2359757d0bf11cc101eec54 +build_name + 100% nova-next +build_node + 100% ubuntu-focal +build_queue + 100% check +build_status + 100% FAILURE +build_zuul_url + 100% N/A +filename + 100% controller/logs/screen-n-cpu.txt +log_url + 50% https://89bc735e8a094e3d60b7-4f6db7cd5400cfa66e1c80fde6bd4076.ssl.cf1.rackcdn.com/792322/1/check/nova-next/de697b4/controller/logs/screen-n-cpu.txt + 50% https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_035/786588/6/check/nova-next/0357703/controller/logs/screen-n-cpu.txt +loglevel + 100% ERROR +module + 33% nova.compute.manager + 33% nova.virt.libvirt.driver + 33% oslo_messaging.rpc.server +node_provider + 50% ovh-bhs1 + 50% rax-iad +port + 50% 48014 + 50% 58238 +project + 100% openstack/nova +syslog_pid + 50% 107528 + 50% 108261 +syslog_program + 50% ubuntu-focal-ovh-bhs1-0024748800 nova-compute + 50% ubuntu-focal-rax-iad-0024745546 nova-compute +tags + 100% screen-n-cpu.txt screen oslofmt +voting + 100% 1 +zuul_attempts + 100% 1 +zuul_executor + 50% ze01.opendev.org + 50% ze07.opendev.org + + +Expected result +=============== +swap_volume at least fails correctly leaving the original device attached. + +Actual result +============= +swap_volume fails and the original device appears detached from the device. + +Environment +=========== +1. Exact version of OpenStack you are running. See the following + list for all releases: http://docs.openstack.org/releases/ + + master + +2. Which hypervisor did you use? + (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) + What's the version of that? + + libvirt + QEMU (no KVM in the gate) + +2. Which storage type did you use? + (For example: Ceph, LVM, GPFS, ...) + What's the version of that? + + images_type=default=qcow2 + +3. Which networking type did you use? + (For example: nova-network, Neutron with OpenVSwitch, ...) + + N/A + +Logs & Configs +============== \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/193 b/results/classifier/gemma3:12b/device/193 new file mode 100644 index 000000000..037a50209 --- /dev/null +++ b/results/classifier/gemma3:12b/device/193 @@ -0,0 +1,2 @@ + +piix crashes on mips when using multiple cpus diff --git a/results/classifier/gemma3:12b/device/1935 b/results/classifier/gemma3:12b/device/1935 new file mode 100644 index 000000000..f04fb102a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1935 @@ -0,0 +1,6 @@ + +migrate problem when add SCSI reservations with iSCSI backed disks +Description of problem: +When performing migrations with QEMU using iSCSI as the backend, it's common for the migration to start successfully. However, in scenarios where Persistent Reservations are added in the guest, the target host, under the precopy mode, preempts the Persistent Reservations right from the beginning, causing migration issues. Is there a way to control the Persistent Reservations lock within QEMU at an appropriate time, ensuring that it's only preempted during the switchover phase？ + +Isn't libiscsi thread-safe? Can multiple threads operate on Persistent Reservations lock simultaneously? diff --git a/results/classifier/gemma3:12b/device/1938 b/results/classifier/gemma3:12b/device/1938 new file mode 100644 index 000000000..92f2494f2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1938 @@ -0,0 +1,37 @@ + +[ARM/PL011] Wrong UART register spacing reported in DBG2/SPCR +Description of problem: +QEMU reports the UART address on aarch64 (for PL011 UART) via the ACPI DBG2 and SPCR tables using the ACPI GAS structure. According to MSFT documentation at https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table: + +> * The Register Bit Width field contains the register stride and must be a power of 2 that is at least as large as the access size. On 32-bit platforms this value cannot exceed 32. On 64-bit platforms this value cannot exceed 64. +> * The Access Size field is used to determine whether byte, WORD, DWORD, or QWORD accesses are to be used. QWORD accesses are only valid on 64-bit architectures. + +For the PL011, the MMIO registers are: +* spaced 4 bytes apart; therefore the reported bit width should be 32 instead of 8. +* 16 bits wide; therefore the access width should be 2 instead of 1. + +In other words: +``` +diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c +index 6b674231c2..cd284676d7 100644 +--- a/hw/arm/virt-acpi-build.c ++++ b/hw/arm/virt-acpi-build.c +@@ -482,7 +482,7 @@ build_spcr(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) + build_append_int_noprefix(table_data, 3, 1); /* ARM PL011 UART */ + build_append_int_noprefix(table_data, 0, 3); /* Reserved */ + /* Base Address */ +- build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1, ++ build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2, + vms->memmap[VIRT_UART].base); + /* Interrupt Type */ + build_append_int_noprefix(table_data, +@@ -673,7 +673,7 @@ build_dbg2(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) + build_append_int_noprefix(table_data, 34, 2); + + /* BaseAddressRegister[] */ +- build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1, ++ build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2, + vms->memmap[VIRT_UART].base); + + /* AddressSize[] */ +``` diff --git a/results/classifier/gemma3:12b/device/1943 b/results/classifier/gemma3:12b/device/1943 new file mode 100644 index 000000000..ffa17b072 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1943 @@ -0,0 +1,25 @@ + +Weird error trying to autodetect CHS disk geometry +Description of problem: +Error: "SSD Read Error" + +Something about the contents of the disk causes qemu to wildly misdetect the disk geometry. +This disk started as a blank disk, and had a FAT filesystem written to it from inside it; thus +writing the detected geometry to the disk. And this caused the detected geometry to change to +something nonsensical. +Steps to reproduce: +1. Unpack the attached [hd.bz2](/uploads/53f5bb00cdd563223bea1f7a0f86fe1c/hd.bz2) to hd.img +2. Run qemu -hda hd.img +3. Observe error +Additional information: +The following command appears to fix the problem; however it is wrong: + +qemu -drive if=none,id=dr,file=hd.img -device ide-hd,drive=dr,cyls=1023,heads=16,secs=63 + +The problem with this command is this command yields only 504MB instead of the 512MB the +disk is actually formatted to be. CHS translation should be enabled on this disk but won't +be with this command. + +This command was copied essentially blindly from "Removed features" because that's what comes +up for a google search for "qemu specify geometry" and I don't understand the command well +enough to correct it. diff --git a/results/classifier/gemma3:12b/device/1948 b/results/classifier/gemma3:12b/device/1948 new file mode 100644 index 000000000..4f2698063 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1948 @@ -0,0 +1,4 @@ + +ARM GICv3 cannot support irq number > 992 +Description of problem: +If we want to create a gic with supported irq number 992, we need to set the `num-irq` property to 992 + 32 while 32 is the extra SGI number. But there is a problem, when QEMU initialize GICv3, it will check the variable `num_irq <= 1020 && (num_irq & 32) == 0`, which will lead to error abort. So there is no way to bypass the ```num_irq <= 1020``` check and we cannot use irq number bigger than 992 while in ARM GIC specification, irq number < 1020 should all be aviliable to use. diff --git a/results/classifier/gemma3:12b/device/1958 b/results/classifier/gemma3:12b/device/1958 new file mode 100644 index 000000000..5ade3634a --- /dev/null +++ b/results/classifier/gemma3:12b/device/1958 @@ -0,0 +1,22 @@ + +PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE] +Description of problem: +When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception. +Additional information: +In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function: + +``` +if (FIELD_EX64(env->msr, MSR, CE)) { + /* Critical doorbell */ + if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) { <- move this part from (async_deliver != 0) + return PPC_INTERRUPT_CDOORBELL; + } + /* External critical interrupt */ + if (env->pending_interrupts & PPC_INTERRUPT_CEXT) { + return PPC_INTERRUPT_CEXT; + } +} +``` + + +And it seems to work in my case. diff --git a/results/classifier/gemma3:12b/device/1960 b/results/classifier/gemma3:12b/device/1960 new file mode 100644 index 000000000..079702538 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1960 @@ -0,0 +1,23 @@ + +Invalid pmu interrupt id in arm virt machine device-tree +Description of problem: +commit 9036e917f8357f4e5965ebfecdab5964d40e6a40 changes the definition of PPI interrupt ID, but forgets to modify the PMU device tree. +The following patch can solve this problem： +``` +diff --git a/hw/arm/virt.c b/hw/arm/virt.c +index dd6bb80ce2..1d118974ee 100644 +--- a/hw/arm/virt.c ++++ b/hw/arm/virt.c +@@ -663,7 +663,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms) + qemu_fdt_setprop(ms->fdt, "/pmu", "compatible", + compat, sizeof(compat)); + qemu_fdt_setprop_cells(ms->fdt, "/pmu", "interrupts", +- GIC_FDT_IRQ_TYPE_PPI, VIRTUAL_PMU_IRQ, irqflags); ++ GIC_FDT_IRQ_TYPE_PPI, INTID_TO_PPI(VIRTUAL_PMU_IRQ), irqflags); + } + } +``` +Steps to reproduce: +NA +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1961 b/results/classifier/gemma3:12b/device/1961 new file mode 100644 index 000000000..029ca1a1f --- /dev/null +++ b/results/classifier/gemma3:12b/device/1961 @@ -0,0 +1,2 @@ + +Commit accel/tcg: Always require can_do_io breaks riscv64 bare metal firmware diff --git a/results/classifier/gemma3:12b/device/1979 b/results/classifier/gemma3:12b/device/1979 new file mode 100644 index 000000000..b16e6caeb --- /dev/null +++ b/results/classifier/gemma3:12b/device/1979 @@ -0,0 +1,32 @@ + +pc-q35-7.2 breaks the pcie hot plugin +Description of problem: +the new pc-q35 version >6.0 break the pcie hot plug feature +if I use 5.2, 6.0, it works fine. `dmesg | grep pcieport` shows that: +there is pciehp which provide functionality of hot plug for PCIE device +``` +[test@localhost ~]$ dmesg | grep pcieport +[ 1.161129] pcieport 0000:00:02.0: PME: Signaling with IRQ 24 +[ 1.162254] pcieport 0000:00:02.0: AER: enabled with IRQ 24 +[ 1.163218] pcieport 0000:00:02.0: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- IbPresDis- LLActRep+ +``` + +if I switch to 6.1, 6.2, 7.0, 7.1 ,7.2, the pciehp does not show any control slot. +``` +[test@localhost ~]$ dmesg | grep pcieport +[ 1.164311] pcieport 0000:00:02.0: PME: Signaling with IRQ 24 +[ 1.165446] pcieport 0000:00:02.0: AER: enabled with IRQ 24 +``` +Steps to reproduce: +1. run the qemu command as I produced +2. connect to console +3. run `dmesg | grep pcieport` +4. you can try to plug in a GPU or something else, the device initialization will fail because there is no pciehp slow to power it on, normall you will see something like following, with >6.0 you cannot see them: + ``` + pciehp: Slot(0-8): Attention button pressed + pciehp: Slot(0-8) Powering on due to button press + pciehp: Slot(0-8): Card present + pciehp: Slot(0-8): Link Up + ``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1984 b/results/classifier/gemma3:12b/device/1984 new file mode 100644 index 000000000..06f087cbe --- /dev/null +++ b/results/classifier/gemma3:12b/device/1984 @@ -0,0 +1,2 @@ + +Fails to start dataplane while using vdpa-dev with vduse backend diff --git a/results/classifier/gemma3:12b/device/1986 b/results/classifier/gemma3:12b/device/1986 new file mode 100644 index 000000000..29e1146ac --- /dev/null +++ b/results/classifier/gemma3:12b/device/1986 @@ -0,0 +1,15 @@ + +windows install fails with error 0x80070001 +Description of problem: +I have a windows vm executed via libvirt, I run it on a physical drive passing it into the guest. when I pass it via sata pt and try to install windows 11 on it, the install fails with error 0x80070001. I had an installation there which resulted with periodic bosd when sata pt was used. +if I pass the /dev node, I don't get the errors but the performance is horrible due to high hdd usage +I've tested the same setup with ubuntu, doing read and write to the device of multiple GB (200GB~), no issue at all. +I've opened an issue at virtio-win and it was closed claiming it is a sata pt issue after trying latest virtio-win. +Steps to reproduce: +1. define a sata virtio controller +2. pass a physical sata drive to the guest attached to the sata controller define in step 1 +3. define a windows iso as cdrom +4. try to install windows on the device +Additional information: +[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt) +[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt) diff --git a/results/classifier/gemma3:12b/device/1991 b/results/classifier/gemma3:12b/device/1991 new file mode 100644 index 000000000..cef788223 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1991 @@ -0,0 +1,65 @@ + +error "hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached" in qemu-system-hppa +Description of problem: +The installation phase terminates with a failed assertion in qemu: +``` +... +Rebooting the system +reboot: Restarting system +SeaBIOS wants SYSTEM RESET. +*************************** +** +ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached +Bail out! ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached +Aborted (core dumped) +``` +Steps to reproduce: +``` +PATH=$HOME/inst-qemu/8.2.0-rc0/bin:$PATH +``` + +Create empty disk: +``` +qemu-img create -f qcow2 t2sde.qcow2 10G +``` + +Pull kernel and initrd out of the installation CD: +``` +sudo mount -r -t iso9660 -o loop t2-23.6-hppa-minimal-desktop-gcc-glibc.iso /mnt +mkdir boot-for-install +cp -p /mnt/boot/* boot-for-install/ +sudo umount /mnt +``` + +Run installer: +``` +machine_args="-M C3700 -m 256" +disk_args="-drive file=t2sde.qcow2,format=qcow2,id=hd0" +net_args="" +#display_args="-monitor stdio -display gtk" +display_args="-nographic" +common_args="$machine_args $disk_args $net_args $display_args" +qemu-system-hppa $common_args \ + -kernel boot-for-install/vmlinux-6.3.7-t2 -initrd boot-for-install/initrd-6.3.7-t2 \ + -drive file=t2-23.6-hppa-minimal-desktop-gcc-glibc.iso,if=scsi,bus=0,unit=2,media=cdrom +``` + +``` +Serial terminal: <Enter> or console +# install +Partition: + fdisk + n p 1 <Enter> <Enter> + w +On /dev/sda1: Create filesystem of type ext3 with mount point / +Install the system +Full install (all packages). +Keyboard: us +Root password: t2 +Time zone: Europe/Berlin +Locale: -- +Finally: <Back> +Then: <Exit> +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/1998 b/results/classifier/gemma3:12b/device/1998 new file mode 100644 index 000000000..7849f2057 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1998 @@ -0,0 +1,28 @@ + +acpihp does not work with some common guest kernels +Description of problem: +for pc-q35 6.1, 7.2, any guest kernel with `ACPI: Core revision` < 20230331, can not hot plug the nvidia GPUs. +So basically only guest kernel >= 6.5 can make it work so far. +But majority of server kernels are still at 4.18, 5.x. I wonder if it possible to be fixed? +I also don't know is this qemu bug? bios bug? or actually ACPIA's bug? + +journal -k report error like following: +``` +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: no space for [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: failed to assign [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 6: assigned [mem 0x81800000-0x8187ffff pref] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 5: assigned [io 0xa000-0xa07f] +Nov 11 17:53:00 VMTEST kernel: nvidia 0000:08:00.0: enabling device (0000 -> 0003) +Nov 11 17:53:00 VMTEST kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: + NVRM: BAR0 is 0M @ 0x0 (PCI:0000:08:00.0) +Nov 11 17:53:00 VMTEST kernel: nvidia: probe of 0000:08:00.0 failed with error -1 +``` +Steps to reproduce: +1. run the instance as I described above +2. in qemu monitor: device_add vfio-pci,host=0000:06:00.0,id=gpu0,bus=pci.8 +3. login to the vm console then nvidia-smi to see the failure + +workaround: +`ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off` to disable the acpihp then pciehp can make it work. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2008 b/results/classifier/gemma3:12b/device/2008 new file mode 100644 index 000000000..fa367dd47 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2014 b/results/classifier/gemma3:12b/device/2014 new file mode 100644 index 000000000..2485e1358 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2016 b/results/classifier/gemma3:12b/device/2016 new file mode 100644 index 000000000..693b58717 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2016 @@ -0,0 +1,10 @@ + +-virtfs not working on windows +Description of problem: +performing the above returns +qemu-system-aarch64.exe: -virtfs abc: There is no option group 'virtfs' +qemu-system-aarch64.exe: -virtfs abc: virtfs support is disabled +Steps to reproduce: +1.qemu-system-aarch64.exe -virtfs abc +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2018 b/results/classifier/gemma3:12b/device/2018 new file mode 100644 index 000000000..ebbf18b6d --- /dev/null +++ b/results/classifier/gemma3:12b/device/2018 @@ -0,0 +1,19 @@ + +QEMU would not start when trying to create two UFS host controllers +Description of problem: +This issue is reported by Akinobu Mita. +https://lore.kernel.org/qemu-devel/20231204150543.48252-1-akinobu.mita@gmail.com/ + +> QEMU would not start when trying to create two UFS host controllers and a UFS logical unit for each with the following options: +> +> -device ufs,id=bus0 \ +> -device ufs-lu,drive=drive1,bus=bus0,lun=0 \ +> -device ufs,id=bus1 \ +> -device ufs-lu,drive=drive2,bus=bus1,lun=0 \ +> +> This is because the same ID string ("0:0:0/scsi-disk") is generated +> for both UFS logical units. +> +> To fix this issue, prepend the parent pci device's path to make +> the ID string unique. +> ("0000:00:03.0/0:0:0/scsi-disk" and "0000:00:04.0/0:0:0/scsi-disk") diff --git a/results/classifier/gemma3:12b/device/2022 b/results/classifier/gemma3:12b/device/2022 new file mode 100644 index 000000000..dd89e5882 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2022 @@ -0,0 +1,12 @@ + +Win32s crashes qemu (regression, bisected) +Description of problem: +Whenever I start a Win32s application (FREECELL.EXE), qemu says "qemu: Bad ram pointer 0x7f4b13a80000" and aborts. I tried a few different versions of Win32s (I specifically remember 1.15a and 1.25a), but it does not seem to matter. I am using only the standard VGA driver and nothing else that would not be present in a standard install of the guest components. +Steps to reproduce: +1. Run any Win32s application +2. +3. +Additional information: +It worked fine before this commit, both on stable-8.1 as well as the master branch: + +4f8f41272e accel: Replace target_ulong with vaddr in probe_*() diff --git a/results/classifier/gemma3:12b/device/2023 b/results/classifier/gemma3:12b/device/2023 new file mode 100644 index 000000000..fca8084bb --- /dev/null +++ b/results/classifier/gemma3:12b/device/2023 @@ -0,0 +1,2 @@ + +[block jobs]qemu hang when creating snapshot target node(iothread enable) diff --git a/results/classifier/gemma3:12b/device/2028 b/results/classifier/gemma3:12b/device/2028 new file mode 100644 index 000000000..ac3de84e9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2028 @@ -0,0 +1,2 @@ + +CAN sja1000 standard frame filter bug diff --git a/results/classifier/gemma3:12b/device/2031 b/results/classifier/gemma3:12b/device/2031 new file mode 100644 index 000000000..42cb4285d --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2033 b/results/classifier/gemma3:12b/device/2033 new file mode 100644 index 000000000..fe19e7f2e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2033 @@ -0,0 +1,2 @@ + +goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL diff --git a/results/classifier/gemma3:12b/device/2045 b/results/classifier/gemma3:12b/device/2045 new file mode 100644 index 000000000..a5fab3eb9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2045 @@ -0,0 +1,2 @@ + +virtio-gpu-*-pci Support reset of virtual GPU from /sys/bus/pci/devices/$NUMBER/reset diff --git a/results/classifier/gemma3:12b/device/2053 b/results/classifier/gemma3:12b/device/2053 new file mode 100644 index 000000000..f69512375 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2053 @@ -0,0 +1,2 @@ + +virtio is broken in qemu-system-arm diff --git a/results/classifier/gemma3:12b/device/2061 b/results/classifier/gemma3:12b/device/2061 new file mode 100644 index 000000000..45e343737 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2061 @@ -0,0 +1,14 @@ + +Regression: QEMU 8.2.0 VFIO GPU guests cannot reboot due to improper reset +Description of problem: +Prior to QEMU 8.2.0 (i.e. 8.1.4), rebooting the guest with VFIO GPU passed through would result in a proper reboot. +After updating to QEMU 8.2.0, rebooting the guest results in a black screen due to improper reset behaviour. +I was able to narrow this down to commit #3d779ab. Compiling and running with commit #0bddd88 results in the correct behaviour. +That is, the GPU properly resets on guest reboot and boots successfully to Windows. +Steps to reproduce: +1. Update to QEMU 8.2.0 +2. Boot Windows 11 23H2 +3. Reboot +4. Notice a black screen +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2065 b/results/classifier/gemma3:12b/device/2065 new file mode 100644 index 000000000..8527882ba --- /dev/null +++ b/results/classifier/gemma3:12b/device/2065 @@ -0,0 +1,2 @@ + +rfe: Cygwin support diff --git a/results/classifier/gemma3:12b/device/206818 b/results/classifier/gemma3:12b/device/206818 new file mode 100644 index 000000000..76a365607 --- /dev/null +++ b/results/classifier/gemma3:12b/device/206818 @@ -0,0 +1,44 @@ + +qemulator.py crashed with IndexError in on_comboboxMachinetype_changed() + +Binary package hint: qemulator + +Hy + +I simply opened qemulator and than qemulator crashed said the bug report utility +but qemulator was open and work . + +i dont know were the error is but i will report it anyway . + +I use: + Ubuntu hardy (development branch) +Release: 8.04 + +qemulator version 0.5-3 + +regards peter + +ProblemType: Crash +Architecture: i386 +Date: Tue Mar 25 22:27:24 2008 +DistroRelease: Ubuntu 8.04 +ExecutablePath: /usr/share/qemulator/qemulator.py +InterpreterPath: /usr/bin/python2.5 +NonfreeKernelModules: nvidia +Package: qemulator 0.5-3 +PackageArchitecture: all +ProcCmdline: python /usr/bin/qemulator +ProcEnviron: + PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games + LANG=en_US.UTF-8 + SHELL=/bin/bash +PythonArgs: ['/usr/bin/qemulator'] +SourcePackage: qemulator +Title: qemulator.py crashed with IndexError in on_comboboxMachinetype_changed() +Traceback: + Traceback (most recent call last): + File "/usr/share/qemulator/qml_machinesetup.py", line 661, in on_comboboxMachinetype_changed + row = model[active] + IndexError: could not find tree path +Uname: Linux 2.6.24-12-386 i686 +UserGroups: adm admin audio cdrom dialout dip fax floppy lpadmin netdev plugdev powerdev sambashare scanner tape video \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/2077 b/results/classifier/gemma3:12b/device/2077 new file mode 100644 index 000000000..4dda063b7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2077 @@ -0,0 +1,2 @@ + +flaky CI test: acpiBitsTest.test_acpi_smbios_bits diff --git a/results/classifier/gemma3:12b/device/2081 b/results/classifier/gemma3:12b/device/2081 new file mode 100644 index 000000000..120a753ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/2081 @@ -0,0 +1,10 @@ + +[OHCI] OHCI_CC_DEVICENOTRESPONDING not set when transferring to a disconnected device +Description of problem: +If a USB device is disconnected and is cleaned up by qemu, subsequent transfers to that device address are ignored. On a real OHCI controller `OHCI_CC_DEVICENOTRESPONDING` bit is set and is reported as an error to the host. + +qemu attempts to set it here https://github.com/qemu/qemu/blob/ffd454c67e38cc6df792733ebc5d967eee28ac0d/hw/usb/hcd-ohci.c#L795 which would work fine on a valid device handle. + +However this check https://github.com/qemu/qemu/blob/ffd454c67e38cc6df792733ebc5d967eee28ac0d/hw/usb/hcd-ohci.c#L975 leaves early if no device handle is found so the error code is never set. + +Fix is to set `OHCI_CC_DEVICENOTRESPONDING` if `ohci_find_device` fails before returning. diff --git a/results/classifier/gemma3:12b/device/2087 b/results/classifier/gemma3:12b/device/2087 new file mode 100644 index 000000000..d554e6415 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2098 b/results/classifier/gemma3:12b/device/2098 new file mode 100644 index 000000000..7c9054b65 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2098 @@ -0,0 +1,2 @@ + +AArch32 Arm CPUs no longer support the 'vfp' property diff --git a/results/classifier/gemma3:12b/device/210 b/results/classifier/gemma3:12b/device/210 new file mode 100644 index 000000000..c2bb0f1a3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/210 @@ -0,0 +1,2 @@ + +Function not implemented when using libaio diff --git a/results/classifier/gemma3:12b/device/2107 b/results/classifier/gemma3:12b/device/2107 new file mode 100644 index 000000000..947374060 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2107 @@ -0,0 +1,2 @@ + +target/riscv: zve32x/zve64x are not supported diff --git a/results/classifier/gemma3:12b/device/2120 b/results/classifier/gemma3:12b/device/2120 new file mode 100644 index 000000000..bcd03ac45 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2120 @@ -0,0 +1,2 @@ + +arm64: Typo in isar_feature_aa64_tidcp1 diff --git a/results/classifier/gemma3:12b/device/2121 b/results/classifier/gemma3:12b/device/2121 new file mode 100644 index 000000000..cac3673e8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2121 @@ -0,0 +1,2 @@ + +tests/qtest/ahci-test.c:89:verify_state: assertion failed (ahci_fingerprint == ahci->fingerprint): (0xe0000000 == 0x29228086) diff --git a/results/classifier/gemma3:12b/device/2131 b/results/classifier/gemma3:12b/device/2131 new file mode 100644 index 000000000..f7819bfba --- /dev/null +++ b/results/classifier/gemma3:12b/device/2131 @@ -0,0 +1,2 @@ + +tcg mem plugin, udata always zero diff --git a/results/classifier/gemma3:12b/device/2132 b/results/classifier/gemma3:12b/device/2132 new file mode 100644 index 000000000..daa230902 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2132 @@ -0,0 +1,12 @@ + +USB Hub as USB Host Device: Child devices not recognized in Win11 +Description of problem: +I wanted to give the Windows environment direct access to some of the physical USB ports on my pc. So I mapped a selection of ports to Windows via the associated hub. Windows correctly recognizes the hub. Also, when devices are plugged into or removed from the associated ports, Windows recognizes the connection of a new device or its removal. However, regardless of the device, Windows reports: +"USB device not recognized. +The last USB device you connected to this computer has malfunctioned, and Windows does not recognize it." +Steps to reproduce: +1. Add one of the hosts USB hubs to a Windows VM as a USB Host Device. +2. Verify that Windows recognizes the host hub in device manager. +3. Try plugging in a USB device into one of the corresponding physical ports. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2134 b/results/classifier/gemma3:12b/device/2134 new file mode 100644 index 000000000..a763cbd5e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2134 @@ -0,0 +1,2 @@ + +[Tricore Board]How to map LOCAL. DSPR/LOCAL.PSPR to other CPU globle_DSPR/globle_PSPR diff --git a/results/classifier/gemma3:12b/device/2138 b/results/classifier/gemma3:12b/device/2138 new file mode 100644 index 000000000..74e41c87f --- /dev/null +++ b/results/classifier/gemma3:12b/device/2138 @@ -0,0 +1,23 @@ + +Build failure on macOS when using --disable-cocoa +Description of problem: +Build fails: + +``` +../qemu-8.2.1/meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Steps to reproduce: +1. On macOS run `./configure --disable-cocoa` + +Result: + +``` +Compiler for language objc skipped: feature cocoa disabled +``` +``` +../meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Additional information: +It seems your build script contains the assumption that an Objective-C compiler is not needed when the Cocoa UI is disabled, but it still appears to be needed to compile the CoreAudio code regardless of UI. + +This was originally reported to MacPorts here: https://trac.macports.org/ticket/67984 diff --git a/results/classifier/gemma3:12b/device/2149 b/results/classifier/gemma3:12b/device/2149 new file mode 100644 index 000000000..194155b3c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2149 @@ -0,0 +1,12 @@ + +Segfault in libvhost-user and libvduse because of invalid pointer arithmetic with indirect read +Description of problem: +Hello, this is my first experience communicating with open-source community. I have already reported the problem and have submitted patches through qemu-devel mailing list https://mail.gnu.org/archive/html/qemu-devel/2024-01/msg02533.html, as instructed in https://www.qemu.org/docs/master/devel/submitting-a-patch.html, albeit getting no response from any maintainer. I know, that everyone are very busy and are spammed everyday from millions of threads, but I am getting very upset, that such a trivial bug lives in code base for many years and even have been copied to "sister"-library without proper review. So, excuse me, if I am taking this issue too personally. + +The problem - when one tries to use libvhost-user\libvduse and triggers for some reason non-zero-copy mode (like pushing a lot of data) of indirect descriptor reading routine `virtqueue_read_indirect_desc`, any time one got to read more than one descriptor - one would overwrite stack and depending on one's luck getting some weird behaviour, or simple crash moments later, when other code tries to access broken data. + +Steps to reproduce are non-trivial, because depends on one's host and VM (one simply gets random crashes here and there, with core dumps pointing somewhere around given libraries), but anyone who can read C code, can clearly see that pointer arithmetic of `struct vring_desc *desc` is wrong. + +Maybe, I got instructions wrong and posted fixes to wrong mailing list, maybe, nobody cares, so thank you for attention. I'll be glad to hear any advice on how can I help with fixing this simple error, besides what has been done already. + +Thank you. diff --git a/results/classifier/gemma3:12b/device/2154 b/results/classifier/gemma3:12b/device/2154 new file mode 100644 index 000000000..34273bdcf --- /dev/null +++ b/results/classifier/gemma3:12b/device/2154 @@ -0,0 +1,8 @@ + +ID_AA64MMFR2_EL1 is all zeros +Description of problem: +When the `ID_AA64MMFR2_EL1` register is read via `mrs x[n], ID_AA64MMFR2_EL1`, it is read as all zeros. This is at the very least not correct for `ID_AA64MMFR2_EL1.ST`, which describes support for small translation tables (FEAT_TTST). +Steps to reproduce: +1. Run `mrs x[n], ID_AA64MMFR2_EL1` within qemu-system-aarch64 +Additional information: +FEAT_TTST is a relatively new aarch64 feature that appears to have caused many problems basically everywhere. However, [qemu has reportedly implemented it](https://www.qemu.org/2021/04/30/qemu-6-0-0/). diff --git a/results/classifier/gemma3:12b/device/2160 b/results/classifier/gemma3:12b/device/2160 new file mode 100644 index 000000000..cf503e8ab --- /dev/null +++ b/results/classifier/gemma3:12b/device/2160 @@ -0,0 +1,2 @@ + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-libusb" diff --git a/results/classifier/gemma3:12b/device/2163 b/results/classifier/gemma3:12b/device/2163 new file mode 100644 index 000000000..d5b6c5594 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2163 @@ -0,0 +1,2 @@ + +Move architecture specific interruption code around SPARC CPUs from hw/sparc/ to target/sparc/ diff --git a/results/classifier/gemma3:12b/device/2164 b/results/classifier/gemma3:12b/device/2164 new file mode 100644 index 000000000..4c421160e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2164 @@ -0,0 +1,8 @@ + +m68k: 68010 exception format is incorrect +Description of problem: +The exception format for the original 68000 is different to the 68010 and QEMU uses the incorrect format for 68010. +Steps to reproduce: +You need to have something that depends on the stack layout (i.e. nommu linux) to notice it. +Additional information: +I have posted a patch to fix it already: https://lists.gnu.org/archive/html/qemu-devel/2024-01/msg02800.html diff --git a/results/classifier/gemma3:12b/device/2174 b/results/classifier/gemma3:12b/device/2174 new file mode 100644 index 000000000..fae96e123 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2174 @@ -0,0 +1,2 @@ + +XenBus machines have almost no hotplug support diff --git a/results/classifier/gemma3:12b/device/2177 b/results/classifier/gemma3:12b/device/2177 new file mode 100644 index 000000000..81a274e8b --- /dev/null +++ b/results/classifier/gemma3:12b/device/2177 @@ -0,0 +1,2 @@ + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-dtc" diff --git a/results/classifier/gemma3:12b/device/2184 b/results/classifier/gemma3:12b/device/2184 new file mode 100644 index 000000000..8c8043b0f --- /dev/null +++ b/results/classifier/gemma3:12b/device/2184 @@ -0,0 +1,54 @@ + +NVMe differences between QEMU v4.1.0 and v8.2.1 +Description of problem: +We are currently upgrading QEMU from v4.1.0 to v8.2.1. In order to keep compatibility between the two QEMUs, we are adding ``-machine pc-q35-4.1``. One of our test is to ensure a guest that has hibernated on the previous QEMU is able to resume on the new one. + +When resuming, we get the following error: + +``` +[ 7.394709] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 +[ 7.926188] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 +[ 7.938235] Read-error on swap-device (259:0:4874880) +[ 7.938237] Read-error on swap-device (259:0:4620184) +[ 7.938240] Read-error on swap-device (259:0:5536464) +[ 7.938311] Read-error on swap-device (259:0:5006840) +[ 7.938316] Read-error on swap-device (259:0:5791888) +[ 7.938386] Read-error on swap-device (259:0:6579728) +[ 7.938391] Read-error on swap-device (259:0:5536680) +[ 7.938431] Read-error on swap-device (259:0:4877384) +[ 7.938434] Read-error on swap-device (259:0:5005376) +[ 7.938457] Read-error on swap-device (259:0:5269328) +[ 7.939200] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 7.939267] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 7.946359] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.063186] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.069556] Aborting journal on device nvme0n1p1-8. +[ 8.069561] Buffer I/O error on dev nvme0n1p1, logical block 262144, lost sync page write +[ 8.069564] JBD2: Error -5 detected when updating journal superblock for nvme0n1p1-8. +[ 8.081218] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.081242] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write +[ 8.081247] EXT4-fs (nvme0n1p1): I/O error while writing superblock +[ 8.147693] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.147753] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write +[ 8.163478] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.174179] EXT4-fs (nvme0n1p1): I/O error while writing superblock +[ 8.198741] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0 +[ 8.214483] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.230322] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0 +[ 8.246249] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b +[ 8.246269] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246291] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246336] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246826] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249232] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249320] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249880] Core dump to |/usr/share/apport/apport pipe failed +``` + +Digging throw the NVMe code, I have found one [patch](https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04202.html) changing the BAR layout. It doesn't look like there is a way to select the previous BAR layout. + +When selecting the ``-machine``, I was expecting that the underlying HW (including devices) would not change. Can you clarify if hibernating from QEMU A and resuming to QEMU B is meant to be supported? +Steps to reproduce: +1. Start the guest with qemu v4.1.0 and an NVME disk +2. Hibernate the OS +3. Resume the guest with qemu v8.2.1 diff --git a/results/classifier/gemma3:12b/device/2185 b/results/classifier/gemma3:12b/device/2185 new file mode 100644 index 000000000..f9513e773 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2185 @@ -0,0 +1,2 @@ + +spapr watchdog should honour watchdog-set-action etc monitor commands diff --git a/results/classifier/gemma3:12b/device/2186 b/results/classifier/gemma3:12b/device/2186 new file mode 100644 index 000000000..a93726187 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2186 @@ -0,0 +1,35 @@ + +riscv virt pflash0 writes not supported +Description of problem: +I am using GDB to debug some Firmware related stuff. At some point in the execution my BIOS/Firmware writes into some global variable (at 0x2000525C) inside the .bss section which is linked to be inside the memory mapped pflash0. But when I step forward with GDB to the exact location where the store instruction (sw) is executed, QEMU prints the following: +``` +pflash_write: Unimplemented flash cmd sequence (offset 000000000000525c, wcycle 0x0 cmd 0x0 value 0x1) +``` +According to the top of `hw/block/pflash_cfi01.c` Flash writes are supported. I was also under the impression that the flash is memory mapped, but maybe that is not true? I am probably missing something here so it would be nice if someone could point me in the right direction. I would also gladly contribute if there is something missing in the riscv virt target. + +I made a simple program to more easily reproduce this: +``` +.section .text +.global _start +_start: + lui a5, 0x20000 + li a4, 5 + sw a4, 24(a5) + +``` +results in QEMU error msg: +``` +pflash_write: Unimplemented flash cmd sequence (offset 0000000000000018, wcycle 0x0 cmd 0x0 value 0x5) +``` +Steps to reproduce: +1. compile above assembly program like this: +``` +riscv64-unknown-elf-gcc -nostdlib -O0 bios.S +riscv64-unknown-elf-objcopy -O binary a.out +truncate -s 33554432 a.out +``` +2. start QEMU like this: +``` +qemu-system-riscv64 -M virt -bios none -drive if=pflash,format=raw,unit=0,file=a.out -nographic -d unimp +``` +3. notice the error message printed by QEMU diff --git a/results/classifier/gemma3:12b/device/2196 b/results/classifier/gemma3:12b/device/2196 new file mode 100644 index 000000000..4363bdfbd --- /dev/null +++ b/results/classifier/gemma3:12b/device/2196 @@ -0,0 +1,2 @@ + +Missing support for video hardware accelerate support in virgl (virtio-gpu) diff --git a/results/classifier/gemma3:12b/device/221 b/results/classifier/gemma3:12b/device/221 new file mode 100644 index 000000000..148a4a9e4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/221 @@ -0,0 +1,2 @@ + +piix crashes on mips when accessing acpi-pci-hotplug diff --git a/results/classifier/gemma3:12b/device/2211 b/results/classifier/gemma3:12b/device/2211 new file mode 100644 index 000000000..032c6d728 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2211 @@ -0,0 +1,28 @@ + +Live Migration Issue - get_pci_config_device: Bad config data +Description of problem: +Hello everybody, +recently i have updated my environment from QEMU 7.1 (Build based from Upstream Code) to QEMU 7.2 (Build based from Upstream Code). +Since the patching went very well, i noticed that Live Migrations are not possible anymore. +It looks like that the Migration Process itself is running fine, but at the moment where QEMU wants to get the VM back live on the destination node, it crashes with the following error: + +``` +internal error: qemu unexpectedly closed the monitor: 2024-03-06T16:05:46.118520Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x34 read: c8 device: dc cmask: ff wmask: 0 w1cmask:0 +2024-03-06T16:05:46.118804Z qemu-system-x86_64: Failed to load PCIDevice:config +2024-03-06T16:05:46.118813Z qemu-system-x86_64: Failed to load virtio-rng:virtio +2024-03-06T16:05:46.118821Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.5:00.0/virtio-rng' +2024-03-06T16:05:46.120947Z qemu-system-x86_64: load of migration failed: Invalid argument +``` + +If i would stop/start the instance in question, live migration is back working. +This let me think that this might be an issue caused by the VM emulation process isn't running with the latest source of QEMU 7.2? + +Could someone please help me to figure out how i could resolve this issue to unblock the live migration capability without restarting all of my instances? +Steps to reproduce: +1. Prepare to Test Systems + - SOURCE = Install with QEMU 7.1 + - DESTINATION = Install with QEMU 7.2 +2. Start an example VM instance on the SOURCE +3. Update QEMU to 7.2 on the SOURCE +4. Start Live Migration from SOURCE to DESTINATION. +5. Error should be raised like mentioned above diff --git a/results/classifier/gemma3:12b/device/2212 b/results/classifier/gemma3:12b/device/2212 new file mode 100644 index 000000000..287836caa --- /dev/null +++ b/results/classifier/gemma3:12b/device/2212 @@ -0,0 +1,18 @@ + +"pci_hp_register failed with error -16" was found in Guest when launching VM with pci-bridge and "-machine q35" +Description of problem: +Host and guest config file configuration: + CONFIG_HOTPLUG_PCI_CPCI=y + CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m + CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m + CONFIG_HOTPLUG_PCI_SHPC=y +Use this configuration kernel to boot QEMU, with the QEMU parameter "-machine q35 -device pci-bridge,id=bridge0,chassis_nr=1". After the guest boot, dmesg will display "shpchp 0000:00:04.0: pci_hp_register failed with error -16". +Steps to reproduce: +1.Boot QEMU + +2.Check dmesg in VM +Additional information: +Error log: +[root@localhost ~]# dmesg | grep pci_hp_register +[ 0.723893] shpchp 0000:00:04.0: pci_hp_register failed with error -16 +[dmesg.log](/uploads/8ce302f996255544b4327d27ea4ac555/dmesg.log) diff --git a/results/classifier/gemma3:12b/device/2213 b/results/classifier/gemma3:12b/device/2213 new file mode 100644 index 000000000..1bd2b31d7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2213 @@ -0,0 +1,16 @@ + +QEMU fails with duplicate SaveStateEntry when using two legacy virtio input devices +Description of problem: +QEMU bails out when it is started with two virtio-input devices running in legacy virtio mode, using two different transports (like PCI and CCW on s390x). +Steps to reproduce: +``` +qemu-system-s390x -M s390-ccw-virtio-2.6 -cpu max -nographic -device virtio-multitouch-pci -device virtio-tablet-ccw +``` +fails with: +``` +qemu-system-s390x: -device virtio-tablet-ccw: savevm_state_handler_insert: Detected duplicate SaveStateEntry: id=virtio-input, instance_id=0x0 +``` +Additional information: +The problem does *not* occur if using modern virtio devices (which automatically happens for -M s390-ccw-virtio-2.7 and newer) or if using virtio-input devices with the same transport (e.g. two PCI devices instead of one PCI and one CCW). + +Also note that the problem only occurs since QEMU 8.1 since older versions did not check for duplicate SaveStateEntries (see commit caa91b3c44cdb2d2921e25 ). diff --git a/results/classifier/gemma3:12b/device/2227 b/results/classifier/gemma3:12b/device/2227 new file mode 100644 index 000000000..fd2541734 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2227 @@ -0,0 +1,37 @@ + +Crash when using the ast2600-a3 device with the "virt" aarch64 machine +Description of problem: +QEMU crashes with a segmentation fault when trying to use the "ast2600-a3" device with the "virt" machine. +Steps to reproduce: +1. Run ``./qemu-system-aarch64 -display none -machine virt -device ast2600-a3`` +Additional information: +Backtrace indicates that it is crashing in the aspeed_soc_ast2600_realize() function: + +``` +#0 memory_region_update_container_subregions (subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2637 +#1 memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2661 +#2 0x0000555555d1bd40 in aspeed_soc_ast2600_realize (dev=<optimized out>, errp=0x7fffffffd870) at ../../devel/qemu/hw/arm/aspeed_ast2600.c:301 +#3 0x0000555555ff26ab in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:510 +#4 0x0000555555ff6edd in property_set_bool (obj=0x555558c4b360, v=<optimized out>, name=<optimized out>, opaque=0x555557cd5b50, errp=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:2358 +#5 0x0000555555ffa25b in object_property_set (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", v=v@entry=0x555558ce0650, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:1472 +#6 0x0000555555ffdb9f in object_property_set_qobject + (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=0x555558cdf270, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/qom-qobject.c:28 +#7 0x0000555555ffa8c4 in object_property_set_bool (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=true, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:1541 +#8 0x0000555555ff319c in qdev_realize (dev=dev@entry=0x555558c4b360, bus=bus@entry=0x0, errp=errp@entry=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:292 +#9 0x0000555555c11be3 in qdev_device_add_from_qdict (opts=opts@entry=0x555558c4a2d0, from_json=from_json@entry=false, errp=0x7fffffffda00, errp@entry=0x55555725b478 <error_fatal>) + at ../../devel/qemu/system/qdev-monitor.c:718 +#10 0x0000555555c12051 in qdev_device_add (opts=0x555557cd2a10, errp=errp@entry=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/qdev-monitor.c:737 +#11 0x0000555555c1720f in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/vl.c:1200 +#12 0x00005555561a29c1 in qemu_opts_foreach + (list=<optimized out>, func=func@entry=0x555555c17200 <device_init_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x55555725b478 <error_fatal>) + at ../../devel/qemu/util/qemu-option.c:1135 +#13 0x0000555555c19aea in qemu_create_cli_devices () at ../../devel/qemu/system/vl.c:2637 +#14 qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2705 +#15 0x0000555555c1d67f in qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2699 +#16 qemu_init (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/vl.c:3736 +#17 0x00005555558f6f59 in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:47 +``` diff --git a/results/classifier/gemma3:12b/device/2228 b/results/classifier/gemma3:12b/device/2228 new file mode 100644 index 000000000..e02cc1e2c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2228 @@ -0,0 +1,9 @@ + +hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed +Description of problem: +It's quite easy to trigger the assertion ``hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed`` +Steps to reproduce: +Run one of the following command lines: +1. ``./qemu-system-aarch64 -display none -machine qcom-dc-scm-v1-bmc -device max1111`` +2. ``./qemu-system-aarch64 -display none -machine fby35-bmc -device max1110`` +3. ``./qemu-system-aarch64 -display none -machine yosemitev2-bmc -device corgi-ssp`` diff --git a/results/classifier/gemma3:12b/device/2229 b/results/classifier/gemma3:12b/device/2229 new file mode 100644 index 000000000..f01701fb7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2229 @@ -0,0 +1,6 @@ + +tcg/tcg.c:813:tcg_register_thread: assertion failed: (n < tcg_max_ctxs) +Description of problem: +When running qemu-system-microblazeel with the xlnx-zynqmp-pmu machine and an additional xlnx-zynqmp-pmu-soc device, TCG crashes via an assertion. +Steps to reproduce: +Run: `` ./qemu-system-microblazeel -machine xlnx-zynqmp-pmu -device xlnx-zynqmp-pmu-soc `` diff --git a/results/classifier/gemma3:12b/device/224 b/results/classifier/gemma3:12b/device/224 new file mode 100644 index 000000000..a7e078fe6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/224 @@ -0,0 +1,2 @@ + +Wrong interrupts generated for I.MX6 FEC controller diff --git a/results/classifier/gemma3:12b/device/2249 b/results/classifier/gemma3:12b/device/2249 new file mode 100644 index 000000000..bf12e79aa --- /dev/null +++ b/results/classifier/gemma3:12b/device/2249 @@ -0,0 +1,34 @@ + +[qemu-system-m68k] [q800] Ishar 1 makes Qemu crash +Description of problem: +qemu-system-m68k crashes when running the classic RPG game "Ishar", this is what can be seen on the TTY console on the host system: + +``` +qemu: fatal: DOUBLE MMU FAULT + +D0 = 000000af A0 = 000b91d2 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000074 A1 = 50f02000 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00067274 F2 = 7fff ffffffffffffffff ( nan) +D3 = f7f6f600 A3 = 40809be0 F3 = 7fff ffffffffffffffff ( nan) +D4 = f8ff2a2a A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan) +D5 = 54aa0027 A5 = 007ef2b8 F5 = 7fff ffffffffffffffff ( nan) +D6 = 0000000a A6 = 000001e3 F6 = 7fff ffffffffffffffff ( nan) +D7 = ffffffe6 A7 = 0000000a F7 = 7fff ffffffffffffffff ( nan) +PC = 00067288 SR = 2218 T:0 I:2 SI XN--- +FPSR = 00000000 ---- + FPCR = 0000 X RN + A7(MSP) = 00000000 A7(USP) = 00000000 ->A7(ISP) = 0000000a +VBR = 0x00000000 +SFC = 0 DFC 5 +SSW 00000445 TCR 0000c000 URP 00000000 SRP 01ff6c00 +DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000 +MMUSR 00000000, fault at fffffffe +./mac: line 5: 806788 Aborted (core dumped) qemu-system-m68k -M q800 -m 32 -bios q800.rom -display sdl -audio driver=alsa -device scsi-hd,scsi-id=0,drive=hd0 -drive file=system71.img,media=disk,format=raw,if=none,id=hd0 -display sdl +``` +Steps to reproduce: +1. Download Ishar 1 Color version (available in https://www.grenier-du-mac.net/fiches/Jeux/ishar1.htm, on the lower part of the page). +2. Copy it to the emulated system and decompress the .sit archive with Stuffit Expander 5.5 +3. Run the game by clicking on it's icon and clicking on "Commandes->Jouer" or pressing Command+J +4. Watch it making qemu-system-m68k crash'n burn! +Additional information: +The same game works fine on current MAME Mac II/Ci emulation, etc. diff --git a/results/classifier/gemma3:12b/device/2253 b/results/classifier/gemma3:12b/device/2253 new file mode 100644 index 000000000..eb2bb3dbb --- /dev/null +++ b/results/classifier/gemma3:12b/device/2253 @@ -0,0 +1,2 @@ + +NO_CAST.INTEGER_OVERFLOW in /hw/net/eepro100.c diff --git a/results/classifier/gemma3:12b/device/2260 b/results/classifier/gemma3:12b/device/2260 new file mode 100644 index 000000000..319cad9b3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2271 b/results/classifier/gemma3:12b/device/2271 new file mode 100644 index 000000000..10d7d2df9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2272 b/results/classifier/gemma3:12b/device/2272 new file mode 100644 index 000000000..f649d55bc --- /dev/null +++ b/results/classifier/gemma3:12b/device/2272 @@ -0,0 +1,22 @@ + +Memory leak in the virtual device applesmc +Description of problem: +In the function _qdev_applesmc_isa_reset_, the device mallocs the _AppleSMCData_ but does not free them, causing a memory leak. + +The following log reveals it: + +``` +==1029295==ERROR: LeakSanitizer: detected memory leaksDirect leak of 80 byte(s) in 2 object(s) allocated from: +#0 0x5574dc600a82 in __interceptor_calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 +#1 0x7f4919b22c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) +#2 0x5574dcdb0dfe in qdev_applesmc_isa_reset qemu/hw/misc/applesmc.c:285:5 +#3 0x5574de30e099 in resettable_phase_hold qemu/hw/core/resettable.c +#4 0x5574de2ef753 in bus_reset_child_foreach qemu/hw/core/bus.c:97:13 +#5 0x5574de30dcfe in resettable_child_foreach qemu/hw/core/resettable.c:96:9 +#6 0x5574de30dcfe in resettable_phase_hold qemu/hw/core/resettable.c:173:5 +#7 0x5574de3059b3 in device_reset_child_foreach qemu/hw/core/qdev.c:276:9 +``` +Steps to reproduce: +1. Build qemu with the sanitizer +2. Boot the Linux kernel with the above command line. +3. Stop the qemu process diff --git a/results/classifier/gemma3:12b/device/2274 b/results/classifier/gemma3:12b/device/2274 new file mode 100644 index 000000000..81bfa5b70 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2274 @@ -0,0 +1,44 @@ + +Assertion failuer in cryptodev_builtin_close_session() +Description of problem: +In the function _cryptodev_builtin_close_session(),_ an assertation happened: + +``` +qemu-fuzz-x86_64: qemu/backends/cryptodev-builtin.c:430: int cryptodev_builtin_close_session(CryptoDevBackend *, uint64_t, uint32_t, CryptoDevCompletionFunc, void *): Assertion `session_id < MAX_NUM_SESSIONS && builtin->sessions[session_id]' failed. +==1256139== ERROR: libFuzzer: deadly signal + #9 0x71acb8c2871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x71acb8c39e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x5af7f624b12b in cryptodev_builtin_close_session qemu/backends/cryptodev-builtin.c:430:5 + #12 0x5af7f60b2860 in virtio_crypto_handle_close_session qemu/hw/virtio/virtio-crypto.c:262:12 + #13 0x5af7f60b2860 in virtio_crypto_handle_ctrl qemu/hw/virtio/virtio-crypto.c:423:19 +``` + +The user could send an invalid session_id to trigger this assertion. +Steps to reproduce: +Here's a simple PoC: + +``` +cat << EOF | qemu-system-x86_64 -display none\ + -machine accel=qtest -m 512M -machine q35 -nodefaults -object \ +cryptodev-backend-builtin,id=cryptodev0 -device \ +virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0008000 +write 0x10800e 0x1 0x01 +write 0xe0008016 0x1 0x01 +write 0xe0008020 0x4 0x00801000 +write 0xe0008028 0x4 0x00c01000 +write 0xe000801c 0x1 0x01 +write 0x110000 0x1 0x05 +write 0x110001 0x1 0x04 +write 0x108002 0x1 0x11 +write 0x108008 0x1 0x48 +write 0x10800c 0x1 0x01 +write 0x108018 0x1 0x10 +write 0x10801c 0x1 0x02 +write 0x10c002 0x1 0x01 +write 0xe000b005 0x1 0x00 +EOF +``` diff --git a/results/classifier/gemma3:12b/device/228 b/results/classifier/gemma3:12b/device/228 new file mode 100644 index 000000000..5ee5db882 --- /dev/null +++ b/results/classifier/gemma3:12b/device/228 @@ -0,0 +1,2 @@ + +TCG test targets missing from 'make check-help' diff --git a/results/classifier/gemma3:12b/device/2283 b/results/classifier/gemma3:12b/device/2283 new file mode 100644 index 000000000..88c58f546 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2283 @@ -0,0 +1,34 @@ + +memory leak in virtio-crypto +Description of problem: +The following log reveals it: + +``` +==1878896==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 48 byte(s) in 1 object(s) allocated from: + #0 0x5646565ec262 in __interceptor_calloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 + #1 0x7f591ec3bc50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x564659227db7 in error_setg_internal qemu/util/error.c:105:5 + #3 0x56465794ad35 in cryptodev_builtin_operation qemu/backends/cryptodev-builtin.c:557:9 + #4 0x5646579550b5 in cryptodev_backend_operation qemu/backends/cryptodev.c:180:16 + #5 0x564657953640 in cryptodev_backend_crypto_operation qemu/backends/cryptodev.c:289:12 + #6 0x56465773a647 in virtio_crypto_handle_request qemu/hw/virtio/virtio-crypto.c:911:19 + #7 0x5646577386a0 in virtio_crypto_handle_dataq qemu/hw/virtio/virtio-crypto.c:938:13 + #8 0x564657734f87 in virtio_crypto_dataq_bh qemu/hw/virtio/virtio-crypto.c:963:9 + #9 0x56465928a6b1 in aio_bh_call qemu/util/async.c:171:5 + #10 0x56465928b58c in aio_bh_poll qemu/util/async.c:218:13 + #11 0x5646591eb398 in aio_dispatch qemu/util/aio-posix.c:423:5 + #12 0x5646592919ce in aio_ctx_dispatch qemu/util/async.c:360:5 + #13 0x7f591ec32d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + +Indirect leak of 36 byte(s) in 1 object(s) allocated from: + #0 0x5646565ec0cd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 + #1 0x7f591e488157 in __vasprintf_internal libio/./libio/vasprintf.c:71:30 +``` +Steps to reproduce: +``` +qemu-system-x86_64 -display none -machine accel=qtest -m 512M -machine q35 -nodefaults -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio < /tmp/reproducer +``` + +[reproducer](/uploads/e0161b0d482bc5dac08929d51e70e7fc/reproducer) diff --git a/results/classifier/gemma3:12b/device/2289 b/results/classifier/gemma3:12b/device/2289 new file mode 100644 index 000000000..a26b00732 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2289 @@ -0,0 +1,2 @@ + +virtio-blk not work in freebsd guest with qemu>=7.0.0 diff --git a/results/classifier/gemma3:12b/device/2293 b/results/classifier/gemma3:12b/device/2293 new file mode 100644 index 000000000..319a47d0f --- /dev/null +++ b/results/classifier/gemma3:12b/device/2293 @@ -0,0 +1,36 @@ + +[u2f-passthru]: pamu2fcfg command will stuck forever in Guest OS of Qemu +Description of problem: +To use FIDO2 user verification we need to run `pamu2fcfg` command which will stuck forever in Guest OS of Qemu + +Passing `-usb -device u2f-passthru,hidraw=/dev/hidraw2` for U2F-Passthrough +Steps to reproduce: +1. Make you have have plugged Yubikey. +2. In Guest shell install package using following command `sudo apt-get install pamu2fcfg` +3. Run $`pamu2fcfg` command will stuck forever. + +**Note:** If I run `pamu2fcfg` in my Ubuntu Host environment it works fine. +Additional information: +**lsusb output:** + +**$lusb** + +Bus 001 Device 002: ID 46f4:0005 **QEMU U2F USB key** + +Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +**Debug Details:** + +When pamu2fcfg was launched following will be the call flow. + +[u2f_key_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251") → [recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204") → [u2f_passthru_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332") → [u2f_passthru_read](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305") → [u2f_passthru_recv_from_host](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329") →[ u2f_transaction_get_from_nonce](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272") → [u2f_send_to_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302") →[ u2f_pending_in_add](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207") → [main_loop_wait](https://github.com/qemu/qemu/blob/master/system/runstate.c#L783 "https://github.com/qemu/qemu/blob/master/system/runstate.c#L783") (stuck here) + +From above call flow looks like guest is waiting for key. + +Even I have tried enabling U2F support flag in Qemu while building but that one was not helping either. + +**References:** + +https://github.com/Yubico/pam-u2f/tree/main + +https://www.qemu.org/docs/master/system/devices/usb-u2f.html diff --git a/results/classifier/gemma3:12b/device/2296 b/results/classifier/gemma3:12b/device/2296 new file mode 100644 index 000000000..94c8e839a --- /dev/null +++ b/results/classifier/gemma3:12b/device/2296 @@ -0,0 +1,98 @@ + +heap-buffer-overflow in virtio-sound +Description of problem: +The following log reveals it: + +``` +==3191578==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000068620 at pc 0x55dadcde4ec5 bp 0x7ffe7f18aef0 sp 0x7ffe7f18aee0 +READ of size 8 at 0x602000068620 thread T0 + #0 0x55dadcde4ec4 in virtio_snd_handle_rx_xfer ../hw/audio/virtio-snd.c:988 + #1 0x55daddffbf5e in virtio_queue_notify ../hw/virtio/virtio.c:2296 + #2 0x55dadd6cff4a in virtio_pci_notify_write ../hw/virtio/virtio-pci.c:1721 + #3 0x55dade0ab336 in memory_region_write_accessor ../system/memory.c:497 + #4 0x55dade0af3d0 in access_with_adjusted_size ../system/memory.c:573 + #5 0x55dade0b5032 in memory_region_dispatch_write ../system/memory.c:1528 + #6 0x55dade0ebb62 in flatview_write_continue_step ../system/physmem.c:2713 + #7 0x55dade0ebfb2 in flatview_write_continue ../system/physmem.c:2743 + #8 0x55dade0ebfb2 in flatview_write ../system/physmem.c:2774 + #9 0x55dade0edd58 in address_space_write ../system/physmem.c:2894 + #10 0x55dadd809972 in qtest_process_command ../system/qtest.c:679 + #11 0x55dadd80c3e2 in qtest_process_inbuf ../system/qtest.c:811 + #12 0x55dade6e79a4 in fd_chr_read ../chardev/char-fd.c:72 + #13 0x7f79b0d29c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) + #14 0x55dade998bcf in glib_pollfds_poll ../util/main-loop.c:287 + #15 0x55dade998bcf in os_host_main_loop_wait ../util/main-loop.c:310 + #16 0x55dade998bcf in main_loop_wait ../util/main-loop.c:589 + #17 0x55dadd810e00 in qemu_main_loop ../system/runstate.c:783 + #18 0x55dade2b703a in qemu_default_main ../system/main.c:37 + #19 0x7f79afe29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #20 0x7f79afe29e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #21 0x55dadcb5a284 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x2ef6284) + +0x602000068620 is located 0 bytes to the right of 16-byte region [0x602000068610,0x602000068620) +allocated by thread T0 here: + #0 0x7f79b18b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 + #1 0x7f79b0d32c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x55dadebf5847 (/home/joey/repo/qemu/build/qemu-system-x86_64+0x4f91847) + +SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/audio/virtio-snd.c:988 in virtio_snd_handle_rx_xfer +Shadow bytes around the buggy address: + 0x0c0480005070: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa + 0x0c0480005080: fa fa 05 fa fa fa 07 fa fa fa 00 03 fa fa fd fd + 0x0c0480005090: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 00 06 + 0x0c04800050a0: fa fa 00 00 fa fa 00 00 fa fa 00 01 fa fa 05 fa + 0x0c04800050b0: fa fa 00 03 fa fa 00 03 fa fa 00 01 fa fa 00 05 +=>0x0c04800050c0: fa fa 00 00[fa]fa 00 00 fa fa 00 04 fa fa 00 00 + 0x0c04800050d0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fa + 0x0c04800050e0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa + 0x0c04800050f0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa + 0x0c0480005100: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa + 0x0c0480005110: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd 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 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none \ +-machine accel=qtest -m 512M -machine q35 -device \ +virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \ +alsa,id=my_audiodev -qtest stdio +outl 0xcf8 0x80001804 +outw 0xcfc 0x06 +outl 0xcf8 0x80001820 +outl 0xcfc 0xe0008000 +write 0xe0008016 0x1 0x03 +write 0xe0008020 0x4 0x00901000 +write 0xe0008028 0x4 0x00a01000 +write 0xe000801c 0x1 0x01 +write 0xe000a004 0x1 0x40 +write 0x10c000 0x1 0x02 +write 0x109001 0x1 0xc0 +write 0x109002 0x1 0x10 +write 0x109008 0x1 0x04 +write 0x10a002 0x1 0x01 +write 0xe000b00d 0x1 0x00 +EOF +``` + +# Possible Fix + +check the user-assigned value in virtio_snd_set_config() diff --git a/results/classifier/gemma3:12b/device/2297 b/results/classifier/gemma3:12b/device/2297 new file mode 100644 index 000000000..f0695bd1c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2297 @@ -0,0 +1,2 @@ + +Incorrect String: PowerMAC (Media Access Control instead of Macintosh) diff --git a/results/classifier/gemma3:12b/device/2299 b/results/classifier/gemma3:12b/device/2299 new file mode 100644 index 000000000..3f0026164 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2299 @@ -0,0 +1,204 @@ + +UFS Device sanitizers error +Description of problem: +Sanitizers error reported by Zheyu Ma zheyuma97@gmail.com + +The following log can reveal it: + +==3619819==ERROR: AddressSanitizer: heap-buffer-overflow on address + +0x62a000011200 at pc 0x7f9f9903a2c3 bp 0x7ffd44e1ee60 sp 0x7ffd44e1e608 + +WRITE of size 20512 at 0x62a000011200 thread T0 + +``` +#0 0x7f9f9903a2c2 in __interceptor_memcpy +``` + +../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 + +``` +#1 0x5f23331ea4fc in memcpy +``` + +/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 + +``` +#2 0x5f23331ea4fc in flatview_read_continue_step +``` + +../system/physmem.c:2818 + +``` +#3 0x5f23331eab72 in flatview_read_continue ../system/physmem.c:2835 + +#4 0x5f23331eadc4 in flatview_read ../system/physmem.c:2865 + +#5 0x5f23331ec2a5 in address_space_read_full ../system/physmem.c:2878 + +#6 0x5f23331ec2a5 in address_space_rw ../system/physmem.c:2906 + +#7 0x5f23326b7ad0 in ufs_dma_read_req_upiu ../hw/ufs/ufs.c:129 + +#8 0x5f23326b7ad0 in ufs_dma_read_upiu ../hw/ufs/ufs.c:185 + +#9 0x5f23326b7ad0 in ufs_exec_req ../hw/ufs/ufs.c:1021 + +#10 0x5f23326b7ad0 in ufs_process_req ../hw/ufs/ufs.c:1066 + +#11 0x5f2333a9160d in aio_bh_call ../util/async.c:171 + +#12 0x5f2333a91f45 in aio_bh_poll ../util/async.c:218 + +#13 0x5f2333a217a9 in aio_dispatch ../util/aio-posix.c:423 + +#14 0x5f2333a90d01 in aio_ctx_dispatch ../util/async.c:360 + +#15 0x7f9f985c4d3a in g_main_context_dispatch +``` + +(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + +``` +#16 0x5f2333a9690f in glib_pollfds_poll ../util/main-loop.c:287 + +#17 0x5f2333a9690f in os_host_main_loop_wait ../util/main-loop.c:310 + +#18 0x5f2333a9690f in main_loop_wait ../util/main-loop.c:589 + +#19 0x5f23329370e0 in qemu_main_loop ../system/runstate.c:783 + +#20 0x5f23333b4d7a in qemu_default_main ../system/main.c:37 + +#21 0x7f9f97629d8f in __libc_start_call_main +``` + +../sysdeps/nptl/libc_start_call_main.h:58 + +``` +#22 0x7f9f97629e3f in __libc_start_main_impl ../csu/libc-start.c:392 + +#23 0x5f2331c8df64 in _start +``` + +(/home/joey/repo/qemu/build/qemu-system-x86_64+0x2ea8f64) + +0x62a000011200 is located 0 bytes to the right of 20480-byte region + +\[0x62a00000c200,0x62a000011200) + +allocated by thread T0 here: + +``` +#0 0x7f9f990b4a57 in __interceptor_calloc +``` + +../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 + +``` +#1 0x7f9f985cdc50 in g_malloc0 +``` + +(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + +``` +#2 0xf0e808deae299ff (<unknown module>) +``` + +SUMMARY: AddressSanitizer: heap-buffer-overflow + +../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 + +in \__interceptor_memcpy + +Shadow bytes around the buggy address: + +0x0c547fffa1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +0x0c547fffa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +0x0c547fffa210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +0x0c547fffa220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +0x0c547fffa230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +=\>0x0c547fffa240:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + +0x0c547fffa250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + +0x0c547fffa260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + +0x0c547fffa270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + +0x0c547fffa280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + +0x0c547fffa290: 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 + +==3619819==ABORTING + +And Here is a simple PoC: + +cat \<\< EOF \\ + +qemu-system-x86_64 \\ + +\-display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \\ + +file=[null-co://,if=none,id=disk0](null-co://,if=none,id=disk0) -device ufs,id=ufs_bus -device \\ + +ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio + +outl 0xcf8 0x80000810 + +outl 0xcfc 0xe0000000 + +outl 0xcf8 0x80000804 + +outw 0xcfc 0x06 + +write 0xe0000058 0x1 0xa7 + +write 0xa 0x1 0x50 + +EOF diff --git a/results/classifier/gemma3:12b/device/230 b/results/classifier/gemma3:12b/device/230 new file mode 100644 index 000000000..9e2e73ea6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/230 @@ -0,0 +1,2 @@ + +Confuse error message in virtio_init_region_cache() diff --git a/results/classifier/gemma3:12b/device/231 b/results/classifier/gemma3:12b/device/231 new file mode 100644 index 000000000..acb476a53 --- /dev/null +++ b/results/classifier/gemma3:12b/device/231 @@ -0,0 +1,2 @@ + +Many leaks from qemu_spice_create_update diff --git a/results/classifier/gemma3:12b/device/2310 b/results/classifier/gemma3:12b/device/2310 new file mode 100644 index 000000000..8f6cd6998 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2310 @@ -0,0 +1,2 @@ + +Virtio devices not working diff --git a/results/classifier/gemma3:12b/device/2311 b/results/classifier/gemma3:12b/device/2311 new file mode 100644 index 000000000..067d56b2a --- /dev/null +++ b/results/classifier/gemma3:12b/device/2311 @@ -0,0 +1,16 @@ + +Possible dereference of NULL +Description of problem: +There is possible dereference of NULL using macro QEMU_LOCK_GUARD(&q->lock) in: +1) /block/nvme.c line [326](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/block/nvme.c#L326) +2) /include/qemu/ratelimit.h line [45](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L45) +3) /include/qemu/ratelimit.h line [88](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L88) + + +The QEMU_MAKE_LOCKABLE(x) macro provides a special case (line [71](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L71) of the lockable.h) if NULL gets into it. Then the macro will return NULL, which will get to the input of the qemu_lockable_auto_lock() function, then to the qemu_lockable_lock() function, where NULL dereference will occur (line [95](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L95)). + +It turns out that the NULL case is provided, but not handled properly. I think a NULL check should be added. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/gemma3:12b/device/2314 b/results/classifier/gemma3:12b/device/2314 new file mode 100644 index 000000000..022748a5b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2315 b/results/classifier/gemma3:12b/device/2315 new file mode 100644 index 000000000..b49395dea --- /dev/null +++ b/results/classifier/gemma3:12b/device/2315 @@ -0,0 +1,13 @@ + +Mouse cursor is flipped / inverted / upside-down with virtio-gpu in some Wayland compositors +Description of problem: +The mouse cursor is flipped: +Steps to reproduce: +1. Install a Linux system with a 6.8.x kernel inside the virtual machine +2. Install sway / wayfire / hyprland, or kwin 6.0.4.1 +3. See the mouse cursor +Additional information: +The [kwin fix](https://invent.kde.org/plasma/kwin/-/commit/a31561c392adf5abcda0284e8049fafcb3701585) just makes use of dumb buffers instead of dmabuf. + +The mouse cursor should be pointing to the maximizing button at the top-right corner: + diff --git a/results/classifier/gemma3:12b/device/2318 b/results/classifier/gemma3:12b/device/2318 new file mode 100644 index 000000000..d451d250d --- /dev/null +++ b/results/classifier/gemma3:12b/device/2318 @@ -0,0 +1,35 @@ + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/gemma3:12b/device/232 b/results/classifier/gemma3:12b/device/232 new file mode 100644 index 000000000..08c3d66e9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/232 @@ -0,0 +1,2 @@ + +I/O write make QXL abort in qxl_set_mode() diff --git a/results/classifier/gemma3:12b/device/2327 b/results/classifier/gemma3:12b/device/2327 new file mode 100644 index 000000000..89e4aec28 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2327 @@ -0,0 +1,62 @@ + +negative shift exponent in cirrus_colorexpand_pattern_transp_0_24() +Description of problem: +My fuzzer detected a runtime error in cirrus_colorexpand_pattern_transp_0_24() + +The stack trace is: + +``` +../hw/display/cirrus_vga_rop2.h:216:23: runtime error: shift exponent -2 is negative + #0 0x5589a028c89a in cirrus_colorexpand_pattern_transp_0_24 hw/display/cirrus_vga_rop2.h:216:23 + #1 0x5589a031e239 in cirrus_bitblt_common_patterncopy hw/display/cirrus_vga.c:689:5 + #2 0x5589a032735d in cirrus_bitblt_cputovideo_next hw/display/cirrus_vga.c:820:13 + #3 0x5589a032cde9 in cirrus_linear_write hw/display/cirrus_vga.c:2365:13 + #4 0x5589a2982823 in memory_region_write_accessor system/memory.c:497:5 + #5 0x5589a2981f05 in access_with_adjusted_size system/memory.c:573:18 + #6 0x5589a297fe69 in memory_region_dispatch_write system/memory.c:1521:16 + #7 0x5589a2a2193e in flatview_write_continue_step system/physmem.c:2749:18 + #8 0x5589a2a211d4 in flatview_write_continue system/physmem.c:2779:19 + #9 0x5589a29f9cfb in flatview_write system/physmem.c:2810:12 + #10 0x5589a29f97c8 in address_space_write system/physmem.c:2930:18 +... +``` +Steps to reproduce: +Arguments:\ +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\ +q35 -nodefaults -device cirrus-vga -display vnc=localhost:99 -L ../pc-bios/"\ +The base addresses of memory regions: + +* cirrus-io, 0x3b0 +* cirrus-low-memory, 0xa0000 +* cirrus-linear-io, 0xe0000000 +* cirrus-bitblt-mmio, 0xe1000000 +* cirrus-mmio, 0xe2000000 + +Reproducer: + +``` +writeb 0xe2000108 0x642a8d58 +writeb 0xe2000117 0x335af91c +writeb 0xe2000118 0x765861ed +writeb 0xe200010d 0x7c3af934 +writeb 0xe2000140 0x33f13baf +clock_step +writeb 0xe01f0e68 0x6ea3696c +writeb 0xe13bc720 0x11bb09ba +readb 0xe2000133 +writeb 0xe033629b 0x80f19dd +writeb 0xe134bba7 0x1eb198f9 +readb 0xe2000680 +writeb 0xe2000b84 0x3f0591fc +clock_step +writeb 0xe003469e 0xdbd627e +writeb 0xe114f2bc 0x41adfe48 +readb 0xe2000cde +readb 0xb269d +writeb 0xe1368066 0x3c9ab77 +readb 0xe12a7fe1 +writeb 0xe0191988 0x7e18b0d1 +EOF +``` +Additional information: +Ack: Chuhong Yuan (hslester96@gmail.com) diff --git a/results/classifier/gemma3:12b/device/2330 b/results/classifier/gemma3:12b/device/2330 new file mode 100644 index 000000000..963beb566 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2330 @@ -0,0 +1,74 @@ + +acpi-erst: divide by zero in make_erst_storage_header() +Description of problem: +When we gives `0` to `record_size` for `acpi-erst` device, below code may triggers divide-by-zero. + +```c +static void make_erst_storage_header(ERSTDeviceState *s) + ... + header->magic = cpu_to_le64(ERST_STORE_MAGIC); + header->record_size = cpu_to_le32(s->default_record_size); + header->version = cpu_to_le16(0x0100); + header->reserved = cpu_to_le16(0x0000); + + /* Compute mapsize */ + mapsz = s->storage_size / s->default_record_size; // devide-by-zero occurs +``` + +`acpi-erst` device refuses invalid value for `record_size` and does appropriate condition check in `check_erst_backend_storage()`, but this check is placed before the function triggering the error when `header->magic` is 0. + +```c +static void check_erst_backend_storage(ERSTDeviceState *s, Error **errp) + ... + /* + * Check if header is uninitialized; HostMemoryBackend inits to 0 + */ + if (le64_to_cpu(header->magic) == 0UL) { + make_erst_storage_header(s); + } + + /* Validity check record_size */ + record_size = le32_to_cpu(header->record_size); + if (!( + (record_size) && /* non zero */ + (record_size >= UEFI_CPER_RECORD_MIN_SIZE) && + (((record_size - 1) & record_size) == 0) && /* is power of 2 */ + (record_size >= 4096) /* PAGE_SIZE */ + )) { + error_setg(errp, "ERST record_size %u is invalid", record_size); + return; + } +``` +Steps to reproduce: +1. make sure `acpi-erst.backing` doesn't exist in current folder. +2. run qemu command. +```bash +./build/qemu-system-i386 -object memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x10000,share=on -device acpi-erst,memdev=erstnvram,record_size=0 +``` +Additional information: +I built qemu from source code with `--enable-sanitizers`, and backtrace is as follows: +```bash +AddressSanitizer:DEADLYSIGNAL +================================================================= +==401519==ERROR: AddressSanitizer: FPE on unknown address 0x55bd0616fd53 (pc 0x55bd0616fd53 bp 0x61f000000e80 sp 0x7fffd16e5d90 T0) + #0 0x55bd0616fd53 in make_erst_storage_header /home/xxx/qemu/build/../hw/acpi/erst.c:401 + #1 0x55bd0616fd53 in check_erst_backend_storage /home/xxx/qemu/build/../hw/acpi/erst.c:431 + #2 0x55bd0616fd53 in erst_realizefn /home/xxx/qemu/build/../hw/acpi/erst.c:973 + #3 0x55bd06268426 in pci_qdev_realize /home/xxx/qemu/build/../hw/pci/pci.c:2093 + #4 0x55bd06557629 in device_set_realized /home/xxx/qemu/build/../hw/core/qdev.c:510 + #5 0x55bd0655ecc8 in property_set_bool /home/xxx/qemu/build/../qom/object.c:2362 + #6 0x55bd0655cec4 in object_property_set /home/xxx/qemu/build/../qom/object.c:1471 + #7 0x55bd06560dec in object_property_set_qobject /home/xxx/qemu/build/../qom/qom-qobject.c:28 + #8 0x55bd0655d30a in object_property_set_bool /home/xxx/qemu/build/../qom/object.c:1541 + #9 0x55bd0632f8cf in qdev_device_add_from_qdict /home/xxx/qemu/build/../system/qdev-monitor.c:719 + #10 0x55bd0632fc91 in qdev_device_add /home/xxx/qemu/build/../system/qdev-monitor.c:738 + #11 0x55bd0633ae7e in device_init_func /home/xxx/qemu/build/../system/vl.c:1203 + #12 0x55bd066e7a50 in qemu_opts_foreach /home/xxx/qemu/build/../util/qemu-option.c:1135 + #13 0x55bd06335421 in qemu_create_cli_devices /home/xxx/qemu/build/../system/vl.c:2640 + #14 0x55bd06335421 in qmp_x_exit_preconfig /home/xxx/qemu/build/../system/vl.c:2709 + #15 0x55bd06338f42 in qemu_init /home/xxx/qemu/build/../system/vl.c:3742 + #16 0x55bd06553e35 in main /home/xxx/qemu/build/../system/main.c:47 + #17 0x7efcdb919d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #18 0x7efcdb919e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #19 0x55bd060ecb24 in _start (/home/xxx/qemu/build/qemu-system-i386+0x32db24) +``` diff --git a/results/classifier/gemma3:12b/device/2340 b/results/classifier/gemma3:12b/device/2340 new file mode 100644 index 000000000..b5cc4f64d --- /dev/null +++ b/results/classifier/gemma3:12b/device/2340 @@ -0,0 +1,34 @@ + +SPARC fp operation INVALID trap hangs on offending instruction. +Description of problem: +An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE. However, instead, the program seems to hang on the offending instruction, never moving forward. + +This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result . The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap. However, the program simply hangs on the FDTOI instruction instead of receiving the signal. + +It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail? + +`#include <ieeefp.h>` + +`main()` + +`{` + + `double val;` + + `int i;` + + `fpsetmask(FP_X_INV);` + + `val = 1000000000000003.0; /* Number that is too large for int */` + + `printf("val is %f\n", val);` + + `i = val;` + + `printf("i is %d\n", i);` + +`}` +Steps to reproduce: +1. Enable IEEE iNValid operation traps in the TEM in the FSR. +2. Generate an instruction that causes an iNValid trap +3. Instruction hangs, no SIGFPE is generated diff --git a/results/classifier/gemma3:12b/device/2341 b/results/classifier/gemma3:12b/device/2341 new file mode 100644 index 000000000..b19f1c899 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2341 @@ -0,0 +1,33 @@ + +IVSHMEM device doesn't work for sharing memory with virtiofsd +Description of problem: +Trying to share a folder on the host to the guest with `virtiofsd` using the `ivshmem-plain` device doesn't work (for memory sharing), while using a NUMA node (with `-numa node,memdev=mem`) works just fine. +Steps to reproduce: +1. Install `virtiofsd` +2. Run `/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir=$HOME --cache always` as a regular user (or with another shared directory, it doesn't matter) +3. Run QEMU with the aforementioned command line as a regular user +4. Wait a bit for the OS to load and `virtiofsd` should error out +Additional information: +`virtiofsd` logs: +``` +[2024-05-09T19:49:15Z WARN virtiofsd::sandbox] Couldn't set the process uid as root: -1 +[2024-05-09T19:49:15Z WARN virtiofsd::sandbox] Couldn't set the process gid as root: -1 +[2024-05-09T19:49:15Z INFO virtiofsd] Waiting for vhost-user socket connection... +[2024-05-09T19:49:16Z INFO virtiofsd] Client connected, servicing requests +[2024-05-09T19:49:22Z ERROR virtiofsd] Waiting for daemon failed: HandleRequest(ReqHandlerError(Custom { kind: Other, error: MissingMemoryMapping })) +``` + +QEMU logs (after virtiofsd errors out and exits): +``` +qemu: Failed to read msg header. Read -1 instead of 12. Original request 0. +qemu: Failed to write msg. Wrote -1 instead of 20. +qemu: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu: Failed to set msg fds. +qemu: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu: Error starting vhost: 5 +qemu: Failed to set msg fds. +qemu: vhost_set_vring_call failed 22 +qemu: Failed to set msg fds. +qemu: vhost_set_vring_call failed 22 +qemu: Unexpected end-of-file before all data were read +``` diff --git a/results/classifier/gemma3:12b/device/2342 b/results/classifier/gemma3:12b/device/2342 new file mode 100644 index 000000000..4b5f2c9bb --- /dev/null +++ b/results/classifier/gemma3:12b/device/2342 @@ -0,0 +1,2 @@ + +DEREF_OF_NULL.RET in qdev-clock.c diff --git a/results/classifier/gemma3:12b/device/2350 b/results/classifier/gemma3:12b/device/2350 new file mode 100644 index 000000000..a5d625d42 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2350 @@ -0,0 +1,15 @@ + +Incorrect RNG_CTRL and RNG_DATA_OUTPUT register offets for Aspeed AST2600 A3 +Description of problem: +hw/misc/aspeed_scu.c has the following lines: + +#define AST2600_RNG_CTRL TO_REG(0x524) +#define AST2600_RNG_DATA TO_REG(0x540) + +The Datasheet for the AST2600 A3 lists the offsets as 0x520 for RNG_CTRL and 0x524 for RNG_DATA. I can confirm that these addresses are correct on the hardware. I don't know if the offsets changed from a previous revision, but since qemu fills the SILICON_REV register with the AST2600_A3_SILICON_REV value for the AST2600, it makes sense to me that it would use the A3 register offsets. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2357 b/results/classifier/gemma3:12b/device/2357 new file mode 100644 index 000000000..065002d47 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2357 @@ -0,0 +1,19 @@ + +assert in dwc2 +Description of problem: +The following log reveals it: + +``` +ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached +Bail out! ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached +Aborted +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-aarch64 -display \ +none -machine accel=qtest, -m 512M -machine raspi2b -m 1G -nodefaults \ +-usb -drive file=null-co://,if=none,format=raw,id=disk0 -device \ +usb-storage,port=1,drive=disk0 -qtest stdio +readl 0x3f980dfb +EOF +``` diff --git a/results/classifier/gemma3:12b/device/2359 b/results/classifier/gemma3:12b/device/2359 new file mode 100644 index 000000000..f9423ad15 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2359 @@ -0,0 +1,33 @@ + +assert in virtio-iommu +Description of problem: +The following log reveals it: + +``` +qemu-system-x86_64: qemu/hw/virtio/virtio-iommu.c:821: void virtio_iommu_handle_command(VirtIODevice *, VirtQueue *): Assertion `sz == output_size' failed. +Aborted +``` +Steps to reproduce: +``` +cat << EOF | \qemu-system-x86_64 \ +-display none -machine accel=qtest -m 512M -machine q35 -nodefaults \ +-device virtio-iommu -qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0004000 +write 0x10000e 0x1 0x01 +write 0xe0004020 0x4 0x00001000 +write 0xe0004028 0x4 0x00101000 +write 0xe000401c 0x1 0x01 +write 0x106000 0x1 0x05 +write 0x100001 0x1 0x60 +write 0x100002 0x1 0x10 +write 0x100009 0x1 0x04 +write 0x10000c 0x1 0x01 +write 0x100018 0x1 0x04 +write 0x10001c 0x1 0x02 +write 0x101003 0x1 0x01 +write 0xe0007001 0x1 0x00 +EOF +``` diff --git a/results/classifier/gemma3:12b/device/2366 b/results/classifier/gemma3:12b/device/2366 new file mode 100644 index 000000000..2eb3d3ff2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2366 @@ -0,0 +1,2 @@ + +qemu8.2 check test failed diff --git a/results/classifier/gemma3:12b/device/2388 b/results/classifier/gemma3:12b/device/2388 new file mode 100644 index 000000000..d25c6df93 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2388 @@ -0,0 +1,18 @@ + +NVMe SQ processing gets stuck when IO queue size is small (for example 4) +Steps to reproduce: +1. Get OSv repo with the NVMe driver and build OSv with the 'Hello World' example: +``` +git clone https://github.com/wkozaczuk/osv.git +cd osv +git checkout nvme_refined +git submodule update --init --recursive +./scripts/setup.py +./scripts/build image=native-example fs=zfs -j$(nproc) +``` +2. Run OSv with NVme on and point to your version of QEMU built with tracing enabled: +``` +./scripts/run.py --qemu-path /home/wkozaczuk/projects/qemu/build/qemu-system-x86_64 --nics=0 --nvme -c 1 --pass-arg "--trace pci_nvme_*" +``` +Additional information: +I am adding both full QEMU logs with NVMe tracing enabled and diff of my changes to QEMU code to add extra logging. diff --git a/results/classifier/gemma3:12b/device/2391 b/results/classifier/gemma3:12b/device/2391 new file mode 100644 index 000000000..462970678 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2391 @@ -0,0 +1,17 @@ + +virglrenderer related -device help failure +Description of problem: +When QEMU is compiled against a recent `virglrenderer` version, running the above command fails like this: +``` +$ qemu-system-x86_64 -device virtio-vga-gl,help +qemu-system-x86_64: -device virtio-vga-gl,help: failed to open module: /usr/bin/../lib/qemu/hw-display-virtio-gpu-gl.so: undefined symbol: qemu_egl_display +``` +Steps to reproduce: +1. build QEMU against latest `virglrenderer` (1.0.1) +2. run the above command +Additional information: +The cause appears to be related to e8a2db94 cc @marcandre.lureau-rh + +Arch only recently updated to latest `virglrenderer` which has exposed the issue. + +Note that the device seems to function correctly in normal usage when combined with -display e.g. `-device virtio-vga-gl -display gtk,gl=on` diff --git a/results/classifier/gemma3:12b/device/2399 b/results/classifier/gemma3:12b/device/2399 new file mode 100644 index 000000000..29d3271ec --- /dev/null +++ b/results/classifier/gemma3:12b/device/2399 @@ -0,0 +1,28 @@ + +division by zero in ide +Description of problem: +The following log reveals it: + +``` +../hw/ide/core.c:659:26: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/core.c:659:26 in AddressSanitizer:DEADLYSIGNAL ================================================================= +==4104568==ERROR：AddressSanitizer：FPE on unknown address 0x559d996a7ec3 (pc 0x559d996a7ec3 bp 0x7ffdcf109da0 sp 0x7ffdcf109a40 T0) +#0 0x559d996a7ec3 in ide_set_sector qemu/hw/ide/core.c:659:26 +#1 0x559d996c8dee in ide_sector_read_cb qemu/hw/ide/core.c:786:5 +#2 0x559d996aa50a in ide_buffered_readv_cb qemu/hw/ide/core.c:684:9 +#3 0x559d9b499289 in blk_aio_complete qemu/block/block-backend.c:1555:9 +#4 0x559d9b4891af in blk_aio_complete_bh qemu/block/block-backend.c:1565:5 +#5 0x559d9bbef6b1 in aio_bh_call qemu/util/async.c:171:5 +#6 0x559d9bbf058c in aio_bh_poll qemu/util/async.c:218:13 +#7 0x559d9bb58a28 in aio_dispatch qemu/util/aio-posix.c:423:5 +#8 0x559d9bbf69ce in aio_ctx_dispatch qemu/util/async.c:360:5 +#9 0x7f51fbc77d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0) +0x55d3a.+0x55d3a) +#10 0x559d9bbfa229 in glib_pollfds_poll qemu/util/main-loop.c:287:9 +#11 0x559d9bbf8b63 in os_host_main_loop_wait qemu/util/main-loop.c:310:5 +#12 0x559d9bbf872c in main_loop_wait qemu/util/main-loop.c:589:11 +#13 0x559d9a2640e7 in qemu_main_loop qemu/system/runstate.c:796:9 +#14 0x559d9b1dcaec in qemu_default_main qemu/system/main.c:37:14 +#15 0x559d9b1dcb37 in main qemu/system/main.c:48:12 +#16 0x7f51fb229d8f in __libc_start_call_main csu/.../sysdeps/nptl/libc_start_call_main.h:58:16 +#17 0x7f51fb229e3f in __libc_start_main csu/../csu/libc-start.c:392:3 #18 0x559d98f20ed4 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x1f93ed4) +``` diff --git a/results/classifier/gemma3:12b/device/241119 b/results/classifier/gemma3:12b/device/241119 new file mode 100644 index 000000000..3e1c4a52a --- /dev/null +++ b/results/classifier/gemma3:12b/device/241119 @@ -0,0 +1,20 @@ + +usb_add of a Creative ZEN unrecognized in guest + +Binary package hint: kvm + +This happens when I add my Creative ZEN to a virtual machine running XP. The device is recognised well at first and drivers are installed correctly. But when trying to connect windows crashes with the classic blue screen It complains about something like usbohci.sys, I can't read well because it crashes too fast. +I have also tried with another virtual machine running Vista, same results. +Any help would be really appreciated! + +I'm using the module kvm-amd with Ubuntu 8.04 + +The USB device has the following ID: 041e:4157 Creative Technology, Ltd + +kvm: + Installed: 1:62+dfsg-0ubuntu7 + Candidate: 1:62+dfsg-0ubuntu7 + Version table: + *** 1:62+dfsg-0ubuntu7 0 + 500 http://archive.ubuntu.com hardy/main Packages + 100 /var/lib/dpkg/status \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/2412 b/results/classifier/gemma3:12b/device/2412 new file mode 100644 index 000000000..a3c491fe6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2412 @@ -0,0 +1,101 @@ + +Race condition in megasas device +Description of problem: +Race condition DoS in megasas device was found during **fuzzing**. I'm not sure about **worst case impact**, but for now I can make a suggestion: worst case might be leading to **DoS**, but probably it's a rabbit hole. So if we dig deeper we might find something like CWE-200 or CWE-202 (Exposure of Sensitive Information to an Unauthorized Actor and so on). Also, I think that we should analyse thread usage in this case and make all operations thread-safe, but it's not my business of course. As a consequence, I do not suggest any patch (at least for now). +Steps to reproduce: +This command: + +`cat << EOF | ./build/qemu-system-x86_64 \`\ +`-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \`\ +`-device megasas -device scsi-cd,drive=null0 -blockdev \`\ +`driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio`\ +`outl 0xcf8 0x80000818`\ +`outl 0xcfc 0xc000`\ +`outl 0xcf8 0x80000804`\ +`outw 0xcfc 0x05`\ +`write 0x20 0x1 0x03`\ +`write 0x26 0x1 0x08`\ +`write 0x27 0x1 0x01`\ +`write 0x30 0x1 0x02`\ +`write 0x40 0x1 0x08`\ +`write 0x57 0x1 0x01`\ +`write 0x5a 0x1 0x08`\ +`outl 0xc03d 0x20000000`\ +`outl 0xc03d 0x00`\ +`EOF`\ +\ +Results in:\ +\ +`[R +0.081916] outl 0xcf8 0x80000818`\ +`[S +0.081986] OK`\ +`OK`\ +`[R +0.082033] outl 0xcfc 0xc000`\ +`[S +0.082083] OK`\ +`OK`\ +`[R +0.082102] outl 0xcf8 0x80000804`\ +`[S +0.082117] OK`\ +`OK`\ +`[R +0.082133] outw 0xcfc 0x05`\ +`[S +0.082926] OK`\ +`OK`\ +`[R +0.082961] write 0x20 0x1 0x03`\ +`[S +0.083688] OK`\ +`OK`\ +`[R +0.083731] write 0x26 0x1 0x08`\ +`[S +0.083754] OK`\ +`OK`\ +`[R +0.083780] write 0x27 0x1 0x01`\ +`[S +0.083799] OK`\ +`OK`\ +`[R +0.083817] write 0x30 0x1 0x02`\ +`[S +0.083850] OK`\ +`OK`\ +`[R +0.083872] write 0x40 0x1 0x08`\ +`[S +0.083903] OK`\ +`OK`\ +`[R +0.083925] write 0x57 0x1 0x01`\ +`[S +0.083947] OK`\ +`OK`\ +`[R +0.083962] write 0x5a 0x1 0x08`\ +`[S +0.083985] OK`\ +`OK`\ +`[R +0.084000] outl 0xc03d 0x20000000`\ +`[S +0.085531] OK`\ +`OK`\ +`[R +0.085570] outl 0xc03d 0x00`\ +`[S +0.085673] OK`\ +`OK`\ +`qemu/include/exec/memory.h:1152:12: runtime error: member access within null pointer of type 'AddressSpace' (aka 'struct AddressSpace')`\ +`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qemu/include/exec/memory.h:1152:12 in` \ +`AddressSanitizer:DEADLYSIGNAL`\ +`=================================================================`\ +`==168244==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x56259b9829ac bp 0x000000000001 sp 0x7ffe62140220 T0)`\ +`==168244==The signal is caused by a READ memory access.`\ +`==168244==Hint: address points to the zero page.`\ + `#0 0x56259b9829ac in address_space_to_flatview qemu/include/exec/memory.h:1152:12`\ + `#1 0x56259b9829ac in address_space_write qemu/build/../system/physmem.c:2929:14`\ + `#2 0x56259b98665e in address_space_unmap qemu/build/../system/physmem.c:3272:9`\ + `#3 0x56259af31dce in dma_memory_unmap qemu/include/sysemu/dma.h:236:5`\ + `#4 0x56259af31dce in dma_blk_unmap qemu/build/../system/dma-helpers.c:93:9`\ + `#5 0x56259af2f220 in dma_complete qemu/build/../system/dma-helpers.c:105:5`\ + `#6 0x56259af2f220 in dma_blk_cb qemu/build/../system/dma-helpers.c:129:9`\ + `#7 0x56259bce7041 in blk_aio_complete qemu/build/../block/block-backend.c:1555:9`\ + `#8 0x56259c224495 in aio_bh_call qemu/build/../util/async.c:171:5`\ + `#9 0x56259c224ca6 in aio_bh_poll qemu/build/../util/async.c:218:13`\ + `#10 0x56259c1b9b89 in aio_dispatch qemu/build/../util/aio-posix.c:423:5`\ + `#11 0x56259c228f40 in aio_ctx_dispatch qemu/build/../util/async.c:360:5`\ + `#12 0x7f2b8c0a07a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)`\ + `#13 0x56259c22a1ed in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9`\ + `#14 0x56259c22a1ed in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5`\ + `#15 0x56259c22a1ed in main_loop_wait qemu/build/../util/main-loop.c:589:11`\ + `#16 0x56259af5159e in qemu_main_loop qemu/build/../system/runstate.c:796:9`\ + `#17 0x56259baefdb4 in qemu_default_main qemu/build/../system/main.c:37:14`\ + `#18 0x7f2b8aff7249 (/lib/x86_64-linux-gnu/libc.so.6+0x27249) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\ + `#19 0x7f2b8aff7304 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27304) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\ + `#20 0x562599f60b70 in _start (qemu/build/qemu-system-x86_64+0x20feb70) (BuildId: 48f1333e9a9d60383d8c9e0db5f690e7c26e1bb2)`\ +`AddressSanitizer can not provide additional info.`\ +`SUMMARY: AddressSanitizer: SEGV qemu/include/exec/memory.h:1152:12 in address_space_to_flatview`\ +`==168244==ABORTING` + +\ +But, if we manually put all of those qtest commands and wait for each command to complete, QEMU doesn't fail. It's because of possible race condition - while QEMU still mapping memory, we already starting to unmap it. It results in this crash. diff --git a/results/classifier/gemma3:12b/device/2415 b/results/classifier/gemma3:12b/device/2415 new file mode 100644 index 000000000..b0fd0beb4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2415 @@ -0,0 +1,54 @@ + +Assertion `r->req.aiocb == NULL' in am53c974 device +Description of problem: +The following log reveals it: + +``` +qemu-truman-x86_64-4467afcc: qemu/hw/scsi/scsi-disk.c:558: void scsi_write_data(SCSIRequest *): Assertion `r->req.aiocb == NULL' failed. +==2957464== ERROR: libFuzzer: deadly signal + #0 0x55e76f00e911 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55e76ef88fb8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 + #2 0x55e76ef6d1b3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 + #3 0x7f83d604251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) + #4 0x7f83d60969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7f83d60969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7f83d60969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7f83d6042475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7f83d60287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7f83d602871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7f83d6039e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x55e76fbb55a5 in scsi_write_data qemu/hw/scsi/scsi-disk.c:558:5 + #12 0x55e76fb95a1f in scsi_req_continue qemu/hw/scsi/scsi-bus.c + #13 0x55e76fbfe0cc in esp_do_dma qemu/hw/scsi/esp.c + #14 0x55e76fc0be39 in handle_ti qemu/hw/scsi/esp.c:1104:9 + #15 0x55e76fc042f6 in esp_run_cmd qemu/hw/scsi/esp.c:1186:9 + #16 0x55e76fc042f6 in esp_reg_write qemu/hw/scsi/esp.c:1304:9 + #17 0x55e76fc1329b in esp_pci_io_write qemu/hw/scsi/esp-pci.c:248:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none\ +-machine accel=qtest, -m 512M -device am53c974,id=scsi -device \ +scsi-hd,drive=disk0 -drive id=disk0,if=none,file=null-co://,format=raw \ +-nodefaults -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc03e 0x030000 +outl 0xc009 0xc1000000 +outl 0xc008 0x8a +outl 0xc00d 0x0 +outl 0xc009 0x00 +outl 0xc00c 0x11 +outl 0xc00d 0x0 +outl 0xc00d 0x00 +outl 0xc00d 0x0 +outw 0xc00f 0x00 +outb 0xc00d 0x0 +outl 0xc00d 0x0 +outl 0xc009 0x41000000 +outb 0xc00c 0x90 +outl 0xc00d 0x0 +EOF +``` diff --git a/results/classifier/gemma3:12b/device/2416 b/results/classifier/gemma3:12b/device/2416 new file mode 100644 index 000000000..3aaf59aba --- /dev/null +++ b/results/classifier/gemma3:12b/device/2416 @@ -0,0 +1,40 @@ + +Assertion failure in virtio_snd_get_qemu_format() +Description of problem: +The following log reveals it: + +``` +ERROR:hw/audio/virtio-snd.c:356:virtio_snd_get_qemu_format: code should not be reached +Bail out! ERROR:hw/audio/virtio-snd.c:356:virtio_snd_get_qemu_format: code should not be reached +Aborted +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none \ +-machine accel=qtest, -m 512M -machine q35 -device \ +virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \ +alsa,id=my_audiodev -qtest stdio +outl 0xcf8 0x80001804 +outw 0xcfc 0x06 +outl 0xcf8 0x80001820 +outl 0xcfc 0xe0008000 +write 0xe0008020 0x4 0x00001000 +write 0xe0008028 0x4 0x00101000 +write 0xe000801c 0x1 0x01 +write 0x10c000 0x1 0x01 +write 0x10c001 0x1 0x01 +write 0x10c014 0x1 0x01 +write 0x10c015 0x1 0x51 +write 0x100001 0x1 0xc0 +write 0x100002 0x1 0x10 +write 0x100008 0x1 0x18 +write 0x10f000 0x1 0x02 +write 0x10f001 0x1 0x01 +write 0x100021 0x1 0xf0 +write 0x100022 0x1 0x10 +write 0x100028 0x1 0x08 +write 0x101006 0x1 0x02 +write 0x101002 0x1 0x02 +write 0xe000b001 0x1 0x00 +EOF +``` diff --git a/results/classifier/gemma3:12b/device/2423 b/results/classifier/gemma3:12b/device/2423 new file mode 100644 index 000000000..b20fd1eb3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2423 @@ -0,0 +1,35 @@ + +`qemu -serial stdio` leaves stdout in non-blocking mode +Description of problem: +When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout. +Steps to reproduce: +Run the following script: + +``` +#!/usr/bin/env bash + +qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio & +PID="$!" +sleep 5 +kill "$PID" +wait "$PID" +echo "EXITING $?" + +sleep 5 +seq 1 400000 +``` + +The seq command will be interrupted prematurely: + +``` +... +5143 +5144 +5145⏎ wResource temporarily unavailable +write: Resource temporarily unavailable +write: Resource temporarily unavailable +``` + +When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600). +Additional information: +Expect a patch from me soon. diff --git a/results/classifier/gemma3:12b/device/2427 b/results/classifier/gemma3:12b/device/2427 new file mode 100644 index 000000000..40a4336fc --- /dev/null +++ b/results/classifier/gemma3:12b/device/2427 @@ -0,0 +1,142 @@ + +Heap-buffer-overflow in virtio-sound +Description of problem: +The following log reveals it: + +``` +==852995==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50400002f2f9 at pc 0x5b291f531ba9 bp 0x7ffd8e80c0a0 sp 0x7ffd8e80c098 +WRITE of size 2 at 0x50400002f2f9 thread T0 + #0 0x5b291f531ba8 in clip_natural_int16_t_from_stereo audio/mixeng_template.h:133:16 + #1 0x5b291f4ea707 in audio_pcm_sw_read audio/audio.c:604:5 + #2 0x5b291f4e9502 in AUD_read audio/audio.c:900:16 + #3 0x5b291e6db7c7 in virtio_snd_pcm_in_cb hw/audio/virtio-snd.c:1279:24 + #4 0x5b291f4f3017 in audio_run_in audio/audio.c:1331:21 + #5 0x5b291f4eda89 in audio_run audio/audio.c:1389:5 + #6 0x5b291fa34311 in alsa_poll_handler audio/alsaaudio.c:205:9 + #7 0x5b2921054bb3 in aio_dispatch_handler util/aio-posix.c:372:9 + #8 0x5b292104b9d5 in aio_dispatch_handlers util/aio-posix.c:414:20 + #9 0x5b292104b4b9 in aio_dispatch util/aio-posix.c:424:5 + #10 0x5b29210ede0e in aio_ctx_dispatch util/async.c:360:5 + #11 0x79b4f927fd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #12 0x5b29210f1851 in glib_pollfds_poll util/main-loop.c:287:9 + #13 0x5b29210f007a in os_host_main_loop_wait util/main-loop.c:310:5 + #14 0x5b29210efc24 in main_loop_wait util/main-loop.c:589:11 + #15 0x5b291f5e5475 in qemu_main_loop system/runstate.c:795:9 + #16 0x5b292067eefb in qemu_default_main system/main.c:37:14 + #17 0x5b292067ef7d in main system/main.c:48:12 + #18 0x79b4f8829d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #19 0x79b4f8829e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + #20 0x5b291e29bef4 in _start (/usr/local/bin/qemu-system-x86_64+0x1c8fef4) + +0x50400002f2f9 is located 1 bytes after 40-byte region [0x50400002f2d0,0x50400002f2f8) +allocated by thread T0 here: + #0 0x5b291e339758 in calloc /home/runner/work/llvm-project/llvm-project/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3 + #1 0x79b4f9288c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #2 0x5b29202d0efd in virtio_queue_notify hw/virtio/virtio.c:2297:9 + #3 0x5b291f3d242e in virtio_pci_notify_write hw/virtio/virtio-pci.c:1721:9 + #4 0x5b29203c82a4 in memory_region_write_accessor system/memory.c:497:5 + #5 0x5b29203c7951 in access_with_adjusted_size system/memory.c:573:18 + #6 0x5b29203c57eb in memory_region_dispatch_write system/memory.c:1521:16 + #7 0x5b292046cb42 in flatview_write_continue_step system/physmem.c:2757:18 + #8 0x5b292046c3c1 in flatview_write_continue system/physmem.c:2787:19 + #9 0x5b29204424c9 in flatview_write system/physmem.c:2818:12 + #10 0x5b2920441f1e in address_space_write system/physmem.c:2938:18 + #11 0x5b291f5d8eac in qtest_process_command system/qtest.c:643:9 + #12 0x5b291f5cfec5 in qtest_process_inbuf system/qtest.c:776:9 + #13 0x5b291f5de05e in qtest_read system/qtest.c:788:5 + #14 0x5b2920d2aef0 in qemu_chr_be_write_impl chardev/char.c:214:9 + #15 0x5b2920d2afb1 in qemu_chr_be_write chardev/char.c:226:9 + #16 0x5b2920d37388 in fd_chr_read chardev/char-fd.c:72:9 + #17 0x5b2920719767 in qio_channel_fd_source_dispatch io/channel-watch.c:84:12 + #18 0x79b4f927fc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + +SUMMARY: AddressSanitizer: heap-buffer-overflow audio/mixeng_template.h:133:16 in clip_natural_int16_t_from_stereo +Shadow bytes around the buggy address: + 0x50400002f000: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f080: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f100: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f180: fa fa 00 00 00 00 00 fa fa fa fd fd fd fd fd fd + 0x50400002f200: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd +=>0x50400002f280: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00[fa] + 0x50400002f300: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f380: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f400: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f480: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd + 0x50400002f500: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd +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 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none \ +-machine accel=qtest, -m 512M -machine q35 -device \ +virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \ +alsa,id=my_audiodev -qtest stdio +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x80001820 +outl 0xcfc 0xe0008000 +write 0xe0008020 0x4 0x00001000 +write 0xe0008028 0x4 0x00101000 +write 0xe0008016 0x1 0x03 +write 0xe0008020 0x4 0x00901000 +write 0xe0008028 0x4 0x00a01000 +write 0xe0008016 0x1 0x00 +write 0xe000801c 0x1 0x01 +write 0xe0008016 0x1 0x03 +write 0xe000801c 0x1 0x01 +write 0x100008 0x1 0x08 +write 0x109008 0x1 0x04 +write 0x11e000 0x1 0x04 +write 0x11e001 0x1 0x01 +write 0x11e004 0x1 0x01 +write 0x100081 0x1 0xe0 +write 0x100082 0x1 0x11 +write 0x100088 0x1 0x08 +write 0x10100a 0x1 0x08 +write 0x151000 0x1 0x01 +write 0x1090c1 0x1 0x10 +write 0x1090c2 0x1 0x15 +write 0x1090c8 0x1 0x04 +write 0x10a00c 0x1 0x0c +write 0x10a002 0x1 0x05 +write 0xe000b00c 0x1 0x03 +write 0x101002 0x1 0x1d +write 0xe000b001 0x1 0x00 +outl 0xcfc 0xe0008000 +outl 0xcf8 0x80001885 +outl 0xcf8 0x80001870 +outl 0xcf8 0x80001878 +inl 0xcfc +outl 0xcf8 0x80001870 +outl 0xcf8 0x80001863 +outl 0xcf8 0x80001853 +inb 0xcfc +outl 0xcf8 0x80001854 +inb 0xcfc +inb 0xcfc +outl 0xcf8 0x80001898 +inb 0xcfc +outl 0xcf8 0x80001899 +outl 0xcf8 0x80001870 +inb 0xcfc +inb 0xcfc +EOF +``` diff --git a/results/classifier/gemma3:12b/device/2428 b/results/classifier/gemma3:12b/device/2428 new file mode 100644 index 000000000..9fd572fb8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2428 @@ -0,0 +1,30 @@ + +Null-pointer-dereference in ufs +Description of problem: +The following log reveals it: + +``` +../hw/ufs/ufs.c:740:13: runtime error: member access within null pointer of type 'UfsSq' (aka 'struct UfsSq') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ufs/ufs.c:740:13 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==848760==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x6220e29edfce bp 0x7fffea0c6cf0 sp 0x7fffea0c6c40 T0) +==848760==The signal is caused by a READ memory access. +==848760==Hint: address points to the zero page. + #0 0x6220e29edfce in ufs_mcq_process_db hw/ufs/ufs.c:740:9 + #1 0x6220e29dc10f in ufs_write_mcq_op_reg hw/ufs/ufs.c:758:13 + #2 0x6220e29d85c6 in ufs_mmio_write hw/ufs/ufs.c:813:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 \ +-display none -machine accel=qtest, -m 512M -M q35 -nodefaults -drive \ +file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \ +ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x02 +write 0xe0001004 0x1 0x01 +EOF +``` diff --git a/results/classifier/gemma3:12b/device/2437 b/results/classifier/gemma3:12b/device/2437 new file mode 100644 index 000000000..a30f3243b --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/244 b/results/classifier/gemma3:12b/device/244 new file mode 100644 index 000000000..364257cc8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/244 @@ -0,0 +1,2 @@ + +MIPS MT dvpe does not regard VPEConf0.MVP diff --git a/results/classifier/gemma3:12b/device/2443 b/results/classifier/gemma3:12b/device/2443 new file mode 100644 index 000000000..b20659b97 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2443 @@ -0,0 +1,19 @@ + +virtio-gpu-gl: "opengl is not available" message is too vague and doesn't suggest how to fix the problem +Description of problem: +I finally compiled qemu for Apple Silicon M2 Pro with opengl enabled and virtglrenderer enabled thanks to instruction from homebrew formula, +but I did it without homebrew nor macports just manually compiling necessary libraries. +Qemu was compiled succesfully with flags: +```` +./configure --target-list=aarch64-softmmu,x86_64-softmmu --enable-cocoa --enable-sdl --enable-virglrenderer --enable-vhost-net --enable-spice-protocol --enable-tools --enable-opengl --enable-pixman --enable-vmnet +```` + +the device is clearly listed: +```` +name "virtio-gpu-device", bus virtio-bus +name "virtio-gpu-gl-device", bus virtio-bus +name "virtio-gpu-gl-pci", bus PCI, alias "virtio-gpu-gl" +name "virtio-gpu-pci", bus PCI, alias "virtio-gpu" +```` + +So why it not working and gives that info while opengl is clearly there and is enabled. diff --git a/results/classifier/gemma3:12b/device/2454 b/results/classifier/gemma3:12b/device/2454 new file mode 100644 index 000000000..66641b272 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2454 @@ -0,0 +1,9 @@ + +sd: assertion in sd_read_byte() +Description of problem: +The following log reveals it: + +``` +ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached +Bail out! ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached Aborted (core dumped) +``` diff --git a/results/classifier/gemma3:12b/device/2455 b/results/classifier/gemma3:12b/device/2455 new file mode 100644 index 000000000..6babaf10e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2455 @@ -0,0 +1,9 @@ + +sdhci: assertion in sdhci_read_dataport() +Description of problem: +The following log reveals it: + +``` +qemu-system-x86_64: qemu/hw/sd/sdhci.c:476: uint32_t sdhci_read_dataport(SDHCIState *, unsigned int): Assertion `s->data_count < s->buf_maxsz' failed. +Aborted (core dumped) +``` diff --git a/results/classifier/gemma3:12b/device/2463 b/results/classifier/gemma3:12b/device/2463 new file mode 100644 index 000000000..579771e22 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2463 @@ -0,0 +1,10 @@ + +allow sifive_e to use more RAM +Description of problem: +For users like me that are still learning RISC bare-metal assembly, searching online you will find many tutorials and examples using sifive_e with Qemu, so it is the easy way to get started. + +I quickly ran into crashes with my tests because I did not realize that sifive_e is limited to 16K of RAM. +I realize the 16K limit is hard coded so that it matches the real hardware, but that makes it very hard to run a variety of tests. +Additional information: +My fork of Qemu changes sifive_e to allow 256MB. +https://github.com/panjea/qemu/commit/97cb89d778ebe3407a969b8282e2e7adb4be2971 diff --git a/results/classifier/gemma3:12b/device/2478 b/results/classifier/gemma3:12b/device/2478 new file mode 100644 index 000000000..9ddd49a91 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2478 @@ -0,0 +1,19 @@ + +STM32F1 STM32VLDicovery board: incorrect clock register setting +Description of problem: +The execution of the program hangs when testing, from libopencm3 clock initialization, the status of the clock in ``rcc_wait_for_osc_ready()``. This function https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/f1/rcc.c#L366 loops until the bit stating that the oscillator is stabilized is set. I am unable to find in qemu this bit being set upon clock initialization, which I believe is an hardware emulation shortcoming. Commenting this line in libopencm3 allows for the emulation to complete correctly, but I believe the error lies in the hardware emulation and not in the libopencm3 test. Reading the status of ``RCC_CR`` from ``gdb-multiarch`` probing the QEMU internal state returns 0, leading to the failure of the test at https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/f1/rcc.c#L353 + +See https://www.st.com/resource/en/reference_manual/rm0008-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf for the expected behavior of this register content on page 99/1136 +``` +7.3.1 Clock control register (RCC_CR) + +Bit 17 HSERDY: External high-speed clock ready flag +Set by hardware to indicate that the HSE oscillator is stable. This bit needs 6 cycles of the +HSE oscillator clock to fall down after HSEON reset. +0: HSE oscillator not ready +1: HSE oscillator ready +``` +Steps to reproduce: +1. git clone --recursive https://github.com/libopencm3/libopencm3-examples +2. make +3. qemu-system-arm -M stm32vldiscovery -nographic -serial mon:stdio -kernel examples/stm32/f1/stm32vl-discovery/usart/usart.elf diff --git a/results/classifier/gemma3:12b/device/2486 b/results/classifier/gemma3:12b/device/2486 new file mode 100644 index 000000000..1456bbc8c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2486 @@ -0,0 +1,13 @@ + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/gemma3:12b/device/2488 b/results/classifier/gemma3:12b/device/2488 new file mode 100644 index 000000000..e1e7cb7ea --- /dev/null +++ b/results/classifier/gemma3:12b/device/2488 @@ -0,0 +1,66 @@ + +m68k: 68030 (?): fmove.p doesn't work (6888[1|2] emulation isn't implemented??) +Description of problem: +The following code should be executing a move to the fpu and then a move from it and then branching. + +``` + ff813590 f2 10 4f 00 fmove.p (A0),FP6 + ff813594 f2 11 6f 7f fmove.p FP6,(A1) {#0x7f} + ff813598 61 00 fe 52 bsr.w SUB_ff8133ec +``` + +However, hitting the instruction at `0xff813590` causes the `PC` to go off into the weeds and then the emulation gets stuck and never proceeds. + +Before executing the instruction the CPU state looks like this + +``` +(qemu) info registers + +CPU#0 +D0 = ffffffff A0 = ff813584 F0 = c004 cc00000000000000 ( -51) +D1 = 0000ffff A1 = 0000335e F1 = c00d a866000000000000 ( -21555) +D2 = 00000002 A2 = ff8138a2 F2 = 401b 91a2b3c000000000 ( 3.0542e+08) +D3 = 00000003 A3 = ff824008 F3 = 3fb4 ab3c4d0000000000 ( 3.54107e-23) +D4 = 00000004 A4 = ff81dbb6 F4 = 3d12 919a22ab33bc4000 (3.84141e-226) +D5 = 00000000 A5 = 00000400 F5 = 1020 8060708090a0b0c0 ( 0) +D6 = 0000000c A6 = 00003790 F6 = 7fff ffffffffffffffff ( nan) +D7 = 00000000 A7 = 0000316e F7 = 7fff ffffffffffffffff ( nan) +PC = ff813590 SR = 2708 T:0 I:7 SI -N--- +FPSR = 00000000 ---- + FPCR = 0000 X RN + A7(MSP) = 00000000 A7(USP) = 80000000 ->A7(ISP) = 00003796 +VBR = 0x0000338e +SFC = 3 DFC 0 +SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000 +DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000 +MMUSR 00000000, fault at 00000000 +``` + +After single stepping: + +``` +(qemu) info registers + +CPU#0 +D0 = ffffffff A0 = ff813584 F0 = c004 cc00000000000000 ( -51) +D1 = 0000ffff A1 = 0000335e F1 = c00d a866000000000000 ( -21555) +D2 = 00000002 A2 = ff8138a2 F2 = 401b 91a2b3c000000000 ( 3.0542e+08) +D3 = 00000003 A3 = ff824008 F3 = 3fb4 ab3c4d0000000000 ( 3.54107e-23) +D4 = 00000004 A4 = ff81dbb6 F4 = 3d12 919a22ab33bc4000 (3.84141e-226) +D5 = 00000000 A5 = 00000400 F5 = 1020 8060708090a0b0c0 ( 0) +D6 = 0000000c A6 = 00003790 F6 = 7fff ffffffffffffffff ( nan) +D7 = 00000000 A7 = 00003166 F7 = 7fff ffffffffffffffff ( nan) +PC = ff8138a2 SR = 2708 T:0 I:7 SI -N--- +FPSR = 00000000 ---- + FPCR = 0000 X RN + A7(MSP) = 00000000 A7(USP) = 80000000 ->A7(ISP) = 0000316e +VBR = 0x0000338e +SFC = 3 DFC 0 +SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000 +DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000 +MMUSR 00000000, fault at 00000000 +``` + +With this code the `VBR` doesn't point at an actual vector table from what I can tell and it is pointing at some memory that contains `0xff8138a2` so I guess it hits the instruction, the FPU isn't implemented so it tries to do an `F-line exception` instead but the vector table doesn't actually contain a handler and it's trying to execute garbage that causes the lock up. + +Basically, I guess I need to implement the 6888[1|2] for this code to work. diff --git a/results/classifier/gemma3:12b/device/2490 b/results/classifier/gemma3:12b/device/2490 new file mode 100644 index 000000000..af2433f42 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2490 @@ -0,0 +1,52 @@ + +Windows: virtio-vga-gl no longer works with current virglrenderer version +Description of problem: +Error occurs, when executing QEMU with virtio-vga-gl device using current virglrenderer: +First the boot screen is shown as expected. +After a short while the screen shows and keeps showing "virtio-vga-gl: Display output is not active." +Console logs: +``` +qemu: GtkGLArea console lacks DMABUF support. +qemu: GtkGLArea console lacks DMABUF support. +qemu: GtkGLArea console lacks DMABUF support. +qemu: GtkGLArea console lacks DMABUF support. +Realize gdk gl context failed: GL-Kontext kann nicht erstellt werden +Realize gdk gl context failed: GL-Kontext kann nicht erstellt werden +virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203 +virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203 +virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203 +``` +Steps to reproduce: +1. Prepare current Msys2/Ucrt64 environment including virglrenderer 1.0.1 by installing QEMU as described in https://www.qemu.org/download/#windows +2. `wget https://download.opensuse.org/distribution/leap/15.3/live/openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` +3. `qemu-system-x86_64.exe -m 1024 -display gtk,gl=on -device virtio-vga-gl -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` +Additional information: +virglrenderer may use certain D3D features starting with virglrenderer 1.0.0, see https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1103 for details + +Given virglrenderer >= 1.0.0, QEMU activates these D3D features since https://gitlab.com/qemu-project/qemu/-/commit/c1600f84ce011a056c9c432c8ad8d77f7f8b9e6f. + +But the current QEMU implementation is broken when using these D3D features. + +git bisect finishes with: +``` +574b64aa6754ba491f51024c5a823a674d48a658 is the first bad commit +commit 574b64aa6754ba491f51024c5a823a674d48a658 +Author: Dmitry Osipenko <dmitry.osipenko@collabora.com> +Date: Mon Jan 29 10:39:21 2024 +0300 + + virtio-gpu: Correct virgl_renderer_resource_get_info() error check + + virgl_renderer_resource_get_info() returns errno and not -1 on error. + Correct the return-value check. + + Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> + Message-Id: <20240129073921.446869-1-dmitry.osipenko@collabora.com> + Cc: qemu-stable@nongnu.org + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> + + contrib/vhost-user-gpu/virgl.c | 6 +++--- + hw/display/virtio-gpu-virgl.c | 2 +- + 2 files changed, 4 insertions(+), 4 deletions(-) +``` diff --git a/results/classifier/gemma3:12b/device/2498 b/results/classifier/gemma3:12b/device/2498 new file mode 100644 index 000000000..e8f38e046 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2498 @@ -0,0 +1,52 @@ + +m68k: fpu: fmovem with multiple control registers has incorrect in memory order +Description of problem: +It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers. + +According to the manual: + +``` +The +registers are always moved in the same order, regardless of the addressing mode +used; the floating-point control register is moved first, followed by the floating-point +status register, and the floating-point instruction address register is moved last. +``` + +Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary. + +Maybe something like this is needed: + +``` diff +commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt) +Author: Daniel Palmer <daniel@thingy.jp> +Date: Tue Aug 13 09:52:54 2024 +0900 + + fix fmovem ordering + +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index 92dc9d8563..64ff2df06e 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + */ + + if (is_write && mode == 4) { +- for (i = 2; i >= 0; i--, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + gen_qemu_store_fcr(s, addr, 1 << i); + if (mask != 1) { + tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG)); +@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + } + tcg_gen_mov_i32(AREG(insn, 0), addr); + } else { +- for (i = 0; i < 3; i++, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + if (is_write) { + gen_qemu_store_fcr(s, addr, 1 << i); + } else { +``` diff --git a/results/classifier/gemma3:12b/device/2499 b/results/classifier/gemma3:12b/device/2499 new file mode 100644 index 000000000..9d3b13842 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2499 @@ -0,0 +1,31 @@ + +m68k: fpu: fsave/frestore should be enabled for 68020/68030 +Description of problem: +valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception. + +I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences. + +``` diff +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index d5d2322329..92dc9d8563 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore) + gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE); + return; + } +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + SRC_EA(env, addr, OS_LONG, 0, NULL); + /* FIXME: check the state frame */ + } else { +@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave) + return; + } + +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + /* always write IDLE */ + TCGv idle = tcg_constant_i32(0x41000000); + DEST_EA(env, insn, OS_LONG, idle, NULL); +``` diff --git a/results/classifier/gemma3:12b/device/2500 b/results/classifier/gemma3:12b/device/2500 new file mode 100644 index 000000000..89c6eb89e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2500 @@ -0,0 +1,5 @@ + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/gemma3:12b/device/2507 b/results/classifier/gemma3:12b/device/2507 new file mode 100644 index 000000000..f213e8322 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2507 @@ -0,0 +1,14 @@ + +m68k: fpu: frestore with NULL state should reset FPU state +Description of problem: +According to the PRM: + +``` +Floating-Point Status Register: Cleared if the state size is NULL; otherwise, not affected. +``` + +But this does not currently happen. +Steps to reproduce: +1. set a value in fpsr +2. do frestore with state size zero +3. read back fpsr and notice it isn't zero. diff --git a/results/classifier/gemma3:12b/device/2513 b/results/classifier/gemma3:12b/device/2513 new file mode 100644 index 000000000..c2668019e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2513 @@ -0,0 +1,14 @@ + +CXL Device Missing PCI_CAP_ID_PM (01h) in CAP List Implementation According to PCIe SPEC +Description of problem: +- The lack of **PCI_CAP_ID_PM (01h)** will not cause any crash or error when running QEMU, but it is violated to the PCIe SPEC. +- When some vendors test the power management capability (e.g., Linux Runtime PM), they must manually implement this CAP list to support the D1/D2/D3_Hot d-states changes. +- We don't see any PCI_CAP_ID_PM (01h) in the CXL rootport or endpoint + + {width=349 height=474} + + +# +Steps to reproduce: +1. Run the qemu-system-x86 (See QEMU command line) +2. sudo lspci -xxx diff --git a/results/classifier/gemma3:12b/device/2518 b/results/classifier/gemma3:12b/device/2518 new file mode 100644 index 000000000..91d9372a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2518 @@ -0,0 +1,15 @@ + +Incorrect vertical mouse leaps on qemu-system-sparc +Description of problem: +In openwin (i.e. X) if you turn the scrollwheel on the mouse 1 click the cursor jumps almost all of the way down the screen. Similarly, just pressing the scroll wheel (middle click) multiple times will sometimes produce similar behavior but the cursor doesn't jump as far. +Steps to reproduce: +- Boot Solaris and log in +- capture the mouse by clicking on the screen +- position the mouse cursor near the top of the screen (just so you can see how far it jumps) +- click the scroll wheel up or down one click and observe the cursor jump downward +Additional information: +The issue is independent of which graphic display is used -- sdl, gtk and vnc all do the same thing. Debugging so far suggests that the problem is related to the fact that `sunmouse_event` in `escc.c` is sending a flood of duplicate events in response to the mouse scroll action. My surmise is that this is causing one byte to be dropped from the 5 byte mouse protocol expected by the Solaris kernel and that it is interpreting a sync byte as a vertical motion byte. + +`sunmouse_event` should not send events with only `dz` non-zero and no button changes. The Mouse Systems Corp spec for the the Sun mouse says that it never sends duplicate events (i.e. an event is produced only if there is non-zero `dx` or `dy` or there has been a button state change), and the mouse protocol has no support for `dz` events. + +I will propose a patch shortly to enforce this (and which has seemingly fixed the problem). diff --git a/results/classifier/gemma3:12b/device/2527 b/results/classifier/gemma3:12b/device/2527 new file mode 100644 index 000000000..492318e09 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2527 @@ -0,0 +1,2 @@ + +bFLT parser doesn't select MMU-less CPU diff --git a/results/classifier/gemma3:12b/device/2534 b/results/classifier/gemma3:12b/device/2534 new file mode 100644 index 000000000..85f20e430 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2534 @@ -0,0 +1,11 @@ + +Solaris cannot be power offed with system_powerdown on qemu-system-sparc +Description of problem: +When a `system_powerdown` is done in the QEMU Monitor, nothing happens. Also happens with `qemu-system-sparc.exe` version 9.1.0-rc3, that is, it's not fixed in newer versions. Looking at [sun4m.c](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/sparc/sun4m.c#L451) code, it registers a system_powerdown handler, but it's not working. +Steps to reproduce: +1. Start the machine with the command line above and wait for the complete OS initialization +2. Open the machine monitor +3. Do a `system_powerdown` command +4. Nothing will happen +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2540 b/results/classifier/gemma3:12b/device/2540 new file mode 100644 index 000000000..cc6cd959a --- /dev/null +++ b/results/classifier/gemma3:12b/device/2540 @@ -0,0 +1,18 @@ + +Machine B-L475E-IOT01A USART devices not functional +Description of problem: +The B-L475E-IOT01A claims to support STM32L4x5 USARTs, UARTs and LPUART (Serial ports) but does not appear to actually function. + +I created a minimal bare metal binary that attempts to write to UART (via printf) but it does not succeed. While debugging it appears that all UART registers for USART1 are zero despite code that is writing to those registers and USART_ISR should have the default value of 0x020000C0 per STM documentation RM0351. The code ends up in an infinite loop waiting for the USART module to become ready but it never does. + +For comparison an almost identical program compiled for the netduino-plus-2 (also an STM32 Cortex-M4 CPU) is able to use USART succesfully. +Steps to reproduce: +1. Clone https://github.com/satur9nine/arm-cortex-qemu-demo/tree/STM_b-l475e-iot01a (note branch is STM_b-l475e-iot01a) +2. Obtain arm-none-eabi-gcc version 13.3.rel1 or higher from ARM or linux package manager and install +3. Go to `STM_b-l475e-iot01a_Build` and run `make all` to produce arm-cortex-qemu-demo.bin +4. Run command provided above (optionally run with additional `-gdb tcp::1234,ipv4 -S` options and attach debugger), observe there is no UART output +5. Repeat steps but with `STM_netduino-plus-2_Build` and observe UART output is produced for comparison +Additional information: +Notice memory located at 0x40013800 which is where USART1 is located shows all zeros. + + diff --git a/results/classifier/gemma3:12b/device/2548 b/results/classifier/gemma3:12b/device/2548 new file mode 100644 index 000000000..bacc484a2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2548 @@ -0,0 +1,407 @@ + +Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed. +Description of problem: +Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed. + +The TD PID needs to be either `USB_TOKEN_IN` or `USB_TOKEN_OUT` in `usb_ep_get`, but in the caller `uhci_handle_td` it may be `USB_TOKEN_SETUP`. + +An unprivileged guest user may be able to reach the assertion, I think this bug is quite akin to CVE-2024-3567 (https://gitlab.com/qemu-project/qemu/-/issues/2273) : + +Users are not directly able to craft URBs, however as a user, one might be able to find a kernel path that would send a TD with PID `USB_TOKEN_SETUP` to QEMU (which is called `USB_PID_SETUP` in Linux). +For instance in the Linux Kernel, `uhci_submit_control` in `drivers/usb/host/uhci-q.c:789` does link a `USB_PID_SETUP` TD to the URB. +Steps to reproduce: +Minimized reproducer: + +``` +cat << EOF | ./qemu/build2/qemu-system-x86_64 -machine q35 -nodefaults \ +-device \ +ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \ +-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,multifunction=on,masterbus=i\ +ch9-ehci-1.0,firstport=0 -device ich9-usb-uhci2,bus=pcie.0,addr=1d.1,mul\ +tifunction=on,masterbus=ich9-ehci-1.0,firstport=2 -device ich9-usb-uhci3\ +,bus=pcie.0,addr=1d.2,multifunction=on,masterbus=ich9-ehci-1.0,firstport\ +=4 -drive if=none,id=usbcdrom,media=cdrom -device \ +usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 -device \ +usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom -qtest stdio +outl 0xcf8 0x8000e900 +inw 0xcfc +outl 0xcf8 0x8000e920 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000e920 +inl 0xcfc +outl 0xcf8 0x8000e920 +outl 0xcfc 0xc001 +outl 0xcf8 0x8000e904 +inw 0xcfc +outl 0xcf8 0x8000e904 +outw 0xcfc 0x7 +outl 0xcf8 0x8000e904 +inw 0xcfc +outl 0xcf8 0x8000ef00 +inw 0xcfc +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000ef10 +inl 0xcfc +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000ef04 +inw 0xcfc +outl 0xcf8 0x8000ef04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000ef04 +inw 0xcfc +outl 0xcf8 0x8000ea00 +inw 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000ea20 +inl 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0xc021 +outl 0xcf8 0x8000ea04 +inw 0xcfc +outl 0xcf8 0x8000ea04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000ea04 +inw 0xcfc +outl 0xcf8 0x8000e800 +inw 0xcfc +outl 0xcf8 0x8000e820 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000e820 +inl 0xcfc +outl 0xcf8 0x8000e820 +outl 0xcfc 0xc041 +outl 0xcf8 0x8000e804 +inw 0xcfc +outl 0xcf8 0x8000e804 +outw 0xcfc 0x7 +outl 0xcf8 0x8000e804 +inw 0xcfc +outl 0xcf8 0x8000fa00 +inw 0xcfc +outl 0xcf8 0x8000fa20 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000fa20 +inl 0xcfc +outl 0xcf8 0x8000fa20 +outl 0xcfc 0xc061 +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000fa24 +inl 0xcfc +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x8000fa04 +inw 0xcfc +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa04 +inw 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0x625f69a0 +outb 0xc040 0x46 +outb 0xc040 0x69 +inb 0xc000 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +clock_step +write 0x0 0x4 0x64657669 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +write 0xff000000 0x8 0x000000ff6c6f6766 +write 0xff000008 0x8 0x8d6c65652d736400 +outb 0xc040 0x69 +outl 0xcf8 0x8000ef76 +outw 0xcfc 0x6563 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +inb 0xc000 +clock_step +write 0x4 0x4 0x64657669 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +write 0xff000000 0x8 0x000000ff6c6f6766 +write 0xff000008 0x8 0x8d6c65652d736400 +outb 0xc040 0x69 +outw 0xc003 0x6769 +outb 0xc040 0x69 +readq 0xe0000074 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +clock_step +write 0x8 0x4 0x00000100 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +write 0xff000000 0x8 0x6465766963656d69 +write 0xff000008 0x8 0x740d00699b652d63 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +clock_step +write 0xc 0x4 0x000000ff +write 0xff000000 0x8 0x0000010000000069 +write 0xff000008 0x8 0x636c395f61707269 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +outw 0xc003 0x6f00 +outb 0xc040 0x69 +outl 0xc053 0x6378616d +clock_step +write 0x10 0x4 0x000000ff +write 0xff000000 0x8 0x6465766963656d69 +write 0xff000008 0x8 0x740d00699b652d63 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +outb 0xc051 0x6d +outb 0xc04f 0x61 +outb 0xc040 0x69 +clock_step +write 0x14 0x4 0x000000ff +write 0xff000000 0x8 0x0000010000000069 +write 0xff000008 0x8 0x636c395f61707269 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +EOF +``` + +# Additional information +The crash report triggered by the reproducer is: + +``` +[R +0.033173] outl 0xcf8 0x8000e900 +[S +0.033189] [R +0.033195] inw 0xcfc +[S +0.033205] [R +0.033212] outl 0xcf8 0x8000e920 +[S +0.033218] [R +0.033222] outl 0xcfc 0xffffffff +[S +0.033231] [R +0.033235] outl 0xcf8 0x8000e920 +[S +0.033241] [R +0.033245] inl 0xcfc +[S +0.033250] [R +0.033255] outl 0xcf8 0x8000e920 +[S +0.033261] [R +0.033265] outl 0xcfc 0xc001 +[S +0.033271] [R +0.033275] outl 0xcf8 0x8000e904 +[S +0.033281] [R +0.033285] inw 0xcfc +[S +0.033290] [R +0.033295] outl 0xcf8 0x8000e904 +[S +0.033300] [R +0.033306] outw 0xcfc 0x7 +[S +0.033755] [R +0.033767] outl 0xcf8 0x8000e904 +[S +0.033774] [R +0.033779] inw 0xcfc +[S +0.033785] [R +0.033792] outl 0xcf8 0x8000ef00 +[S +0.033798] [R +0.033802] inw 0xcfc +[S +0.033808] [R +0.033813] outl 0xcf8 0x8000ef10 +[S +0.033818] [R +0.033840] outl 0xcfc 0xffffffff +[S +0.033848] [R +0.033853] outl 0xcf8 0x8000ef10 +[S +0.033859] [R +0.033864] inl 0xcfc +[S +0.033870] [R +0.033875] outl 0xcf8 0x8000ef10 +[S +0.033880] [R +0.033884] outl 0xcfc 0xe0000000 +[S +0.033891] [R +0.033895] outl 0xcf8 0x8000ef04 +[S +0.033901] [R +0.033904] inw 0xcfc +[S +0.033909] [R +0.033916] outl 0xcf8 0x8000ef04 +[S +0.033922] [R +0.033926] outw 0xcfc 0x7 +[S +0.034381] [R +0.034389] outl 0xcf8 0x8000ef04 +[S +0.034395] [R +0.034399] inw 0xcfc +[S +0.034405] [R +0.034412] outl 0xcf8 0x8000ea00 +[S +0.034417] [R +0.034421] inw 0xcfc +[S +0.034427] [R +0.034431] outl 0xcf8 0x8000ea20 +[S +0.034437] [R +0.034441] outl 0xcfc 0xffffffff +[S +0.034448] [R +0.034452] outl 0xcf8 0x8000ea20 +[S +0.034457] [R +0.034463] inl 0xcfc +[S +0.034469] [R +0.034474] outl 0xcf8 0x8000ea20 +[S +0.034480] [R +0.034484] outl 0xcfc 0xc021 +[S +0.034490] [R +0.034494] outl 0xcf8 0x8000ea04 +[S +0.034500] [R +0.034504] inw 0xcfc +[S +0.034509] [R +0.034515] outl 0xcf8 0x8000ea04 +[S +0.034521] [R +0.034525] outw 0xcfc 0x7 +[S +0.034948] [R +0.034955] outl 0xcf8 0x8000ea04 +[S +0.034961] [R +0.034965] inw 0xcfc +[S +0.034971] [R +0.034989] outl 0xcf8 0x8000e800 +[S +0.034996] [R +0.035000] inw 0xcfc +[S +0.035005] [R +0.035010] outl 0xcf8 0x8000e820 +[S +0.035016] [R +0.035020] outl 0xcfc 0xffffffff +[S +0.035027] [R +0.035033] outl 0xcf8 0x8000e820 +[S +0.035039] [R +0.035043] inl 0xcfc +[S +0.035048] [R +0.035053] outl 0xcf8 0x8000e820 +[S +0.035059] [R +0.035065] outl 0xcfc 0xc041 +[S +0.035071] [R +0.035075] outl 0xcf8 0x8000e804 +[S +0.035081] [R +0.035084] inw 0xcfc +[S +0.035089] [R +0.035094] outl 0xcf8 0x8000e804 +[S +0.035100] [R +0.035103] outw 0xcfc 0x7 +[S +0.035525] [R +0.035532] outl 0xcf8 0x8000e804 +[S +0.035538] [R +0.035542] inw 0xcfc +[S +0.035548] [R +0.035553] outl 0xcf8 0x8000fa00 +[S +0.035558] [R +0.035562] inw 0xcfc +[S +0.035567] [R +0.035572] outl 0xcf8 0x8000fa20 +[S +0.035578] [R +0.035581] outl 0xcfc 0xffffffff +[S +0.035589] [R +0.035594] outl 0xcf8 0x8000fa20 +[S +0.035600] [R +0.035604] inl 0xcfc +[S +0.035609] [R +0.035613] outl 0xcf8 0x8000fa20 +[S +0.035618] [R +0.035623] outl 0xcfc 0xc061 +[S +0.035629] [R +0.035633] outl 0xcf8 0x8000fa24 +[S +0.035638] [R +0.035642] outl 0xcfc 0xffffffff +[S +0.035648] [R +0.035652] outl 0xcf8 0x8000fa24 +[S +0.035658] [R +0.035664] inl 0xcfc +[S +0.035669] [R +0.035673] outl 0xcf8 0x8000fa24 +[S +0.035679] [R +0.035683] outl 0xcfc 0xe0001000 +[S +0.035689] [R +0.035696] outl 0xcf8 0x8000fa04 +[S +0.035702] [R +0.035706] inw 0xcfc +[S +0.035711] [R +0.035716] outl 0xcf8 0x8000fa04 +[S +0.035722] [R +0.035725] outw 0xcfc 0x7 +[S +0.036402] [R +0.036412] outl 0xcf8 0x8000fa04 +[S +0.036418] [R +0.036422] inw 0xcfc +[S +0.036434] [R +0.036442] outl 0xcf8 0x8000ea20 +[S +0.036448] [R +0.036463] outl 0xcfc 0x625f69a0 +[S +0.036906] [I +0.036981] CLOSED +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] inb 0xc000 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x0 0x4 0x64657669 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x8000ef76 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xcfc 0x6563 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] inb 0xc000 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x4 0x4 0x64657669 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc003 0x6769 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] readq 0xe0000074 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x8 0x4 0x00000100 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x6465766963656d69 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xc 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x0000010000000069 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x636c395f61707269 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc003 0x6f00 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xc053 0x6378616d +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x6465766963656d69 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc051 0x6d +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc04f 0x61 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x14 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x0000010000000069 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x636c395f61707269 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +qemu-fuzz-x86_64: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +==892641== ERROR: libFuzzer: deadly signal + #0 0x557dd985fc41 in __sanitizer_print_stack_trace (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x20b2c41) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #1 0x557dd97cfa58 in fuzzer::PrintStackTrace() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2022a58) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #2 0x557dd97b5ae3 in fuzzer::Fuzzer::CrashCallback() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2008ae3) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #3 0x7fd7e623c45f (/lib/x86_64-linux-gnu/libc.so.6+0x3c45f) (BuildId: d320ce4e63925d698610ed423fc4b1f0e8ed51f1) + #4 0x7fd7e629152a in __pthread_kill_implementation nptl/pthread_kill.c:43:17 + #5 0x7fd7e629152a in __pthread_kill_internal nptl/pthread_kill.c:78:10 + #6 0x7fd7e629152a in pthread_kill nptl/pthread_kill.c:89:10 + #7 0x7fd7e623c3b5 in raise signal/../sysdeps/posix/raise.c:26:13 + #8 0x7fd7e622287b in abort stdlib/abort.c:79:7 + #9 0x7fd7e622279a in __assert_fail_base assert/assert.c:92:3 + #10 0x7fd7e6233b65 in __assert_fail assert/assert.c:101:3 + #11 0x557dda3b67c6 in usb_ep_get /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/core.c:744:5 + #12 0x557dda3d8820 in uhci_handle_td /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:819:14 + #13 0x557dda3d41ed in uhci_process_frame /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1022:15 + #14 0x557dda3cbf7e in uhci_frame_timer /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1121:9 + #15 0x557ddb90c0ff in timerlist_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:576:9 + #16 0x557ddb90d3e8 in qemu_clock_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:590:12 + #17 0x557ddb90d3e8 in qemu_clock_advance_virtual_time /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:696:9 + #18 0x557dda67fa2f in qtest_process_command /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:722:9 + #19 0x557dda67b3bb in qtest_process_inbuf /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:776:9 + #20 0x557dda67acf6 in qtest_server_inproc_recv /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:907:9 + #21 0x557ddb5fa3e2 in qtest_sendf /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:640:5 + #22 0x557ddb5fa4f4 in qtest_clock_step_next /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:1009:5 + #23 0x557ddb67c2ef in generic_fuzz /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/generic_fuzz.c:667:13 + #24 0x557ddb66e807 in LLVMFuzzerTestOneInput /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/fuzz.c:158:5 + #25 0x557dd97b6f52 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2009f52) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #26 0x557dd97a1080 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff4080) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #27 0x557dd97a6d07 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff9d07) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #28 0x557dd97d0292 in main (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2023292) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #29 0x7fd7e6223a8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #30 0x7fd7e6223b48 in __libc_start_main csu/../csu/libc-start.c:360:3 + #31 0x557dd979b884 in _start (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1fee884) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) +``` diff --git a/results/classifier/gemma3:12b/device/2549 b/results/classifier/gemma3:12b/device/2549 new file mode 100644 index 000000000..cda127962 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2549 @@ -0,0 +1,4 @@ + +qemu-system-arm, ast2400-a1, The ECC_TEST_CTRL register of aspeed_2400_sdmc_write is not implemented +Additional information: +The ast2400-a1 has a few more memory test modes compared to the ast2500-a2 (1xxb in 8:6 and 11b in 2:1), but I think it should be enough to always return a test pass result. diff --git a/results/classifier/gemma3:12b/device/255 b/results/classifier/gemma3:12b/device/255 new file mode 100644 index 000000000..6e14ddfc2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/255 @@ -0,0 +1,2 @@ + +Build on sparc64 fails with "undefined reference to `fdt_check_full'" diff --git a/results/classifier/gemma3:12b/device/2576 b/results/classifier/gemma3:12b/device/2576 new file mode 100644 index 000000000..bc6952560 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2576 @@ -0,0 +1,2 @@ + +virtio-balloon: Assertion `mrs.mr' failed. diff --git a/results/classifier/gemma3:12b/device/2586 b/results/classifier/gemma3:12b/device/2586 new file mode 100644 index 000000000..3a68bb41a --- /dev/null +++ b/results/classifier/gemma3:12b/device/2586 @@ -0,0 +1,4 @@ + +qemu-system-x86_64: IGD "legacy mode" support with Q35? +Additional information: +Detailed discussion on https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12103 diff --git a/results/classifier/gemma3:12b/device/2588 b/results/classifier/gemma3:12b/device/2588 new file mode 100644 index 000000000..90fe41f02 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2588 @@ -0,0 +1,44 @@ + +qemu-system-arm regression: NonSecure World can change Secure World MMU mapping. +Description of problem: +A NonSecure execution context is able to override MMU L1 translation table +flags set by Secure context on Secure World memory. + +This is not consistent with the same code running on real hardware and it's a +regression over past qemu releases as 9.0.0 behaves correctly. +Steps to reproduce: +This has been tested with +[GoTEE-example](https://github.com/usbarmory/GoTEE-example) as follows: + +``` +# building tamago +wget https://github.com/usbarmory/tamago-go/archive/refs/tags/latest.zip +unzip latest.zip +cd tamago-go-latest/src && ./all.bash +cd ../bin && export TAMAGO=`pwd`/go + +# building and running GoTEE-example +wget https://github.com/usbarmory/GoTEE-example/archive/refs/heads/master.zip +unzip master.zip +cd GoTEE-example +export TARGET=usbarmory && make clean && make nonsecure_os_go && make trusted_applet_go && make trusted_os && make qemu +``` + +# +Additional information: +The issue relates to the fact that the NonSecure World, at startup, configures +the MMU with the NX bit for the entire address space not belonging to its +firmware .text area. + +On real hardware this MMU configuration by NonSecure world does not affect the +Secure World translation tables. + +On qemu 9.1.0, however it does and this is inconsistent with real hardware +behavior. On qemu 9.0.0 the behaviour is correct so the issue has been +introduced between these two releases. + +The switch between Secure and NonSecure is done +[here](https://github.com/usbarmory/GoTEE/blob/7e62563c0628fed3ee0aebb4702e22be9bb636e3/monitor/exec_arm.s#L73). + +The MMU first level address table which sets the NX bit is done +[here](https://github.com/usbarmory/tamago/blob/273d67cd811dfcb1782c0fe596ac14d43d0ce117/arm/mmu.go#L85). diff --git a/results/classifier/gemma3:12b/device/259 b/results/classifier/gemma3:12b/device/259 new file mode 100644 index 000000000..9a8420913 --- /dev/null +++ b/results/classifier/gemma3:12b/device/259 @@ -0,0 +1,2 @@ + +dma_blk_cb leaks memory map handles on misaligned IO diff --git a/results/classifier/gemma3:12b/device/2594 b/results/classifier/gemma3:12b/device/2594 new file mode 100644 index 000000000..4a00a37c6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2594 @@ -0,0 +1,36 @@ + +Migration fails with 'get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0' after hotplugging a CPU +Description of problem: +After hotplugging a CPU and finishing a migration from node 1 to node 2, the instance on node 2 crashes when virtio block devices are used: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load virtio-blk:virtio +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +qemu-system-x86_64: load of migration failed: Invalid argument +``` + +I found the problem also exhibits when using `scsi-hd` in combination with `virtio-scsi`, but not when using IDE hard disks or SCSI disks with an LSI controller. VMs with network cards aren't affected either, as are VMs without virtio disks. + + +Interestingly, the latest QEMU version shipped with Ubuntu 20.04 (4.2.1-Debian 1:4.2-3ubuntu6.29) is able to migrate this VM just fine. +Steps to reproduce: +1. Start a VM using the first command line +2. Start another VM using the second command line +3. Hotplug a CPU in QMP: + ``` + {"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"}} + ``` +4. Start a migration by executing the following QMP command (again substituting `<ip:port>` with the IP:port combination of node 2 + ``` + {"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"}} + ``` + +(For steps 3 and 4 I used this): +``` +echo '{"execute":"qmp_capabilities"} +{"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"},"id":1} +{"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"},"id":2}' | nc -U /tmp/vm1.sock +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2609 b/results/classifier/gemma3:12b/device/2609 new file mode 100644 index 000000000..4beba3f1c --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2610 b/results/classifier/gemma3:12b/device/2610 new file mode 100644 index 000000000..be08ade1a --- /dev/null +++ b/results/classifier/gemma3:12b/device/2610 @@ -0,0 +1,2 @@ + +pl011: incorrect IBRD_MASK and FBRD_MASK diff --git a/results/classifier/gemma3:12b/device/2611 b/results/classifier/gemma3:12b/device/2611 new file mode 100644 index 000000000..9fed70a4c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2611 @@ -0,0 +1,4 @@ + +[Documentation]What is a Block driver? +Additional information: +Using Windows 11 but can use Linux diff --git a/results/classifier/gemma3:12b/device/2615 b/results/classifier/gemma3:12b/device/2615 new file mode 100644 index 000000000..f1bc89346 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2615 @@ -0,0 +1,11 @@ + +tpm_emulator: the qemu process will be blocked while receiving an unexpected ctrl command's response from the swtpm +Description of problem: +When the swtpm sends the unexpected ctrl command's repsonse to the qemu process, the qemu will be blocked. When we use the gdb to attach the qemu process, we will find out that the qemu process is blocked in `recv_msg` function. +Steps to reproduce: +1.The QEMU process sends a `CMD_GET_TPMESTABLISHED` control command to the swtpm. +2.If the swtpm is not currently active (`tpm_running` is false), it responds to the QEMU process with an err_not_running message, which has a fixed size of 4 bytes. +(Reference: https://github.com/stefanberger/swtpm/blob/master/src/swtpm/ctrlchannel.c#L938) +3. However, the QEMU process expects to receive a valid response (ptm_est est) of 8 bytes. Consequently, the QEMU process will be blocked in the recv_msg function if the response does not match the expected format. +Additional information: +After analysing the source codes in `tpm_emulator.c`, we found that qemu does not process the unexpected ctrol command response from the swtpm correctly (e.g. `CMD_GET_TPMESTABLISHED`). The qemu would be blocked in this function if it received unexpected response from the swtpm (https://gitlab.com/qemu-project/qemu/-/blob/3e9f48bcdabe57f8f90cf19f01bbbf3c86937267/backends/tpm/tpm_emulator.c#L140). diff --git a/results/classifier/gemma3:12b/device/2616 b/results/classifier/gemma3:12b/device/2616 new file mode 100644 index 000000000..c3a6400af --- /dev/null +++ b/results/classifier/gemma3:12b/device/2616 @@ -0,0 +1,12 @@ + +crashout on any storage operation on SCO OpenServer 6 +Description of problem: +it's hard to exactly pinpoint what's wrong, but apparently it's a known issue. whenever i attempt to install or boot the OS, i get one of the two outcomes: with KVM it's a halt-and-catch-fire, getting stuck in an eternal loop of I/O errors and failed interrupts, with TCG at the very least the drivers get loaded and the installation disk is mounted, contrary to the emulated hard drive. connecting either drive to SCSI made HBA act like it's not there at all, and using the standard AHCI/IDE controllers leads to the result presented in the picture in one of the sections below, and, as mentioned earlier, this stage only happens with TCG. there's a 9:1 shot (on Q35, on PIIX3/PIIX4 it'll always either throw this exception or fail to initialise the CD-ROM) of it either screaming about a power failure right as it's ready to format the drive or it just installing. +Steps to reproduce: +1. download the old OpenServer 6 VM image/ISO from the SCO/Xinuos server. +2. attach it in your config. +3. go through initial setup stages (eg. entering a licence or deferring from such). +4. wait for the disk initialisation to begin. +Additional information: + + diff --git a/results/classifier/gemma3:12b/device/2621 b/results/classifier/gemma3:12b/device/2621 new file mode 100644 index 000000000..1e8fb40e1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2630 b/results/classifier/gemma3:12b/device/2630 new file mode 100644 index 000000000..78d0f751e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2630 @@ -0,0 +1,2 @@ + +Issue template broken diff --git a/results/classifier/gemma3:12b/device/2631 b/results/classifier/gemma3:12b/device/2631 new file mode 100644 index 000000000..5c94da5a1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2631 @@ -0,0 +1,82 @@ + +qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Description of problem: +While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality. +Steps to reproduce: +Here is qtest reproducer: +```bash +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +``` + +and execution log: +``` +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +[I 0.000001] OPENED +[R +0.067760] outl 0xcf8 0x80001020 +[S +0.067795] OK +OK +[R +0.067821] outl 0xcfc 0xe0800000 +[S +0.067959] OK +OK +[R +0.067993] outl 0xcf8 0x80001004 +[S +0.068005] OK +OK +[R +0.068020] outw 0xcfc 0x02 +[S +0.068520] OK +OK +[R +0.068554] write 0xe0800010 0x4 0x6100 +qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Aborted +``` + +If you need more information, let me know so I can discuss more about this issue. +Additional information: +```c +int msix_init(PCIDevice *dev, unsigned short nentries, + MemoryRegion *table_bar, uint8_t table_bar_nr, + unsigned table_offset, MemoryRegion *pba_bar, + uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos, + Error **errp); +int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries, + uint8_t bar_nr, Error **errp); +``` + +`msix_init` accepts `nentries` as `unsigned short` type. + +```c +static void virtio_pci_device_plugged(DeviceState *d, Error **errp): + + ... + + if (proxy->nvectors) { + int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors, + proxy->msix_bar_idx, NULL); + if (err) { + /* Notice when a system that supports MSIx can't initialize it */ + if (err != -ENOTSUP) { + warn_report("unable to init msix vectors to %" PRIu32, + proxy->nvectors); + } + proxy->nvectors = 0; + } + } +``` + +When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`. +This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash. + +While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration. diff --git a/results/classifier/gemma3:12b/device/2635 b/results/classifier/gemma3:12b/device/2635 new file mode 100644 index 000000000..376db2eca --- /dev/null +++ b/results/classifier/gemma3:12b/device/2635 @@ -0,0 +1,13 @@ + +A use-after-free bug in pflash_cfi01 snapshot implementation +Description of problem: +The flash snapshot restore does not function correctly. Basically when you use “if=pflash,format=raw,unit=0,file=OVMF_VAR.fd", it crashes when trying to restore a snapshot. + +The root cause is: + +1. In system/runstate.c, function vm_state_notify loops through vm_change_state_head list and calls the callback function for each entry. +2. One of the callback function pointer points to function postload_update_cb in hw/block/pflash_cfi01.c. +3. In function postload_update_cb, it calls qemu_del_vm_change_state_handler in which the entry element memory is freed. +4. Note that, it is still running in the loop, the entry will be visited and get executed, the function pointer may point to a wide memory. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2639 b/results/classifier/gemma3:12b/device/2639 new file mode 100644 index 000000000..3810d87e7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2648 b/results/classifier/gemma3:12b/device/2648 new file mode 100644 index 000000000..06a152b7c --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2653 b/results/classifier/gemma3:12b/device/2653 new file mode 100644 index 000000000..4d12308c3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2653 @@ -0,0 +1,2 @@ + +Intel iGPU sriov diff --git a/results/classifier/gemma3:12b/device/2655 b/results/classifier/gemma3:12b/device/2655 new file mode 100644 index 000000000..cd9d010c1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2655 @@ -0,0 +1,40 @@ + +A problem in target/riscv/vector_helper.c: vext_ldff() +Description of problem: +I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c: +``` +static inline void +vext_ldff(...) +{ +... + for (i = env->vstart; i < env->vl; i++) { +... + if (i == 0) { + probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD); + } else { +... + flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD, + mmu_index, true, &host, 0); +... + if (flags & ~TLB_WATCHPOINT) { + vl = i; + goto ProbeSuccess; + } +... + } + } +ProbeSuccess: +... +} +``` +If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist. + +In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? + +This problem occurred in both linux-user mode and full-system mode. + +Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions. +Steps to reproduce: +1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests. +2. Write a plugin to add memory callbacks. +3. Observe the behavior of the function. diff --git a/results/classifier/gemma3:12b/device/2661 b/results/classifier/gemma3:12b/device/2661 new file mode 100644 index 000000000..830500c70 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2661 @@ -0,0 +1,34 @@ + +powerpc: MSR_LE implemented incorrectly for processors before PPC970 +Description of problem: +qemu does not emulate MSR_LE correctly for CPUs prior to PPC970. + +The implementation used in this scenario appears to be correct for newer PowerPC CPUs, but not for earlier ones. + +When MSR_LE is enabled on PowerPC G4 and prior CPUs, big endian accesses are performed, with the lower address bits XORed by a constant derived from the size of the access (8-bit: XOR 7, 16-bit: XOR 6, 32-bit: XOR 4, 64-bit and above: no operation). This means that anything loaded in big-endian mode, when byteswapped as 64-bit values, appears in the correct place in little endian mode. + +Any unaligned access is dealt with at the same time. I have not verified exactly what the real hardware does, but the following appears to be correct for 16- and 32-bit accesses (and technically 8-bit accesses too given that all operations but the XOR do nothing in that case): +```c +// sizeof_access is the access size in bytes +size_t temp = ea & (sizeof_access - 1); // get offset of unaligned access +ea &= ~sizeof_access; // align the address +ea ^= (sizeof(uint64_t) - sizeof_access); // perform MSR_LE swizzle +ea -= temp; // correct the address for the unaligned access +``` + +Note that the algorithm can be run again on a swizzled address, which will compute the original non-swizzled address. + +Additionally, GDB memory accesses need to be performed byte-wise using the same algorithm. (there's probably a faster way to do this involving bswap64, though!) + +As for the rest of the system: different chipsets did different things. Some memory controllers (for example those used in early PReP systems) had an endianness swap bit that endianness swapped all of memory and MMIO correctly (given MSR_LE swizzled addresses); later systems with a PCI bus had an endianness swap bit in the PCI host controller (Apple "Bandit", Motorola MPC105/6/7) that endianness swapped PCI address space from the CPU side and provided a correct view of main memory from PCI DMA. + +I'm not sure how to implement any of that, hence testing with mac99, where the PCI host controller is big-endian only (there is a uni-north register to swap PCI endianness, but it isn't implemented in hardware and flipping it does nothing). On such systems, hardware access-related swapping must be handled in software. +Steps to reproduce: +Booting from the correct `nt_arcfw_mac99.iso` will crash on a black screen instead of running the ppcel stage2 bootloader. +Additional information: +The following patch is my implementation. This is my first attempt at QEMU TCG-related code; in some places it may be 'too' safe (running the swizzling algorithm again to revert it in case the EA is used again afterwards), and it also uses the "internal only" `tcg_temp_free_*` functions, to avoid wasting temporary variables. So hopefully some more experienced devs can improve it. + +[msr_le.patch](/uploads/3f829ac58d9943faa0cad7b817569f1d/msr_le.patch) + +The following ISO is the one used for testing. +[nt_arcfw_mac99.iso](/uploads/16aa5406284bab55ada205d6598e399a/nt_arcfw_mac99.iso) diff --git a/results/classifier/gemma3:12b/device/2666 b/results/classifier/gemma3:12b/device/2666 new file mode 100644 index 000000000..ae4e0f423 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2666 @@ -0,0 +1,23 @@ + +OPENSTEP 4.2 for Intel does not boot from SCSI cd connected to am53c974 +Description of problem: +Get OPENSTEP 4.2 installation media from +https://fsck.technology/software/NeXT/OpenStep%20Installation%20Media/ + +Boot qemu like command line above + +Follow on-screen instruction, do not forgot to "change floppy0 path_to_driver_disk.img" in qemu monitor +Additional information: + + +driver select screen + + + +it boots .. + + + +find a bit too much LUNs and eventually give up after scanning them all + +Note there is 0-sized disk "detected" in there somewhere diff --git a/results/classifier/gemma3:12b/device/2671 b/results/classifier/gemma3:12b/device/2671 new file mode 100644 index 000000000..7d4fa7fb9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2671 @@ -0,0 +1,18 @@ + +[Virtio-GPU Venus] I compiled virglrenderer with Venus support on 1.1.0,but could not boot QEMU with virtio-gpu Venus +Description of problem: +When I tried to use virtio-gpu-gl with venus=true like the template,it shows: +{width=1251 height=75} +But I have already compile virglrenderer using: + meson setup build \ + -Dvenus=true \ + -Drender-server=true \ + -Drender-server-worker=thread \ + -Dbuildtype=release \ + -Dprefix=${INSTDIR} + +and run QEMU with designated environment variables,but it still cannot boot,but if I use QEMU-8.0 with Venus-v17 patch and it works😭 +Steps to reproduce: +Just use "-device virtio-gpu-gl,hostmem=4G,blob=true,venus=true" and it will show the problem +Additional information: +No diff --git a/results/classifier/gemma3:12b/device/2675 b/results/classifier/gemma3:12b/device/2675 new file mode 100644 index 000000000..89e501e90 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2675 @@ -0,0 +1,12 @@ + +q800 machine is broken when compiling with --enable-cfi +Description of problem: +When compiling QEMU that is configured like this: +``` + .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang +``` +the q800 machine crashes with an illegal exception on the host very early, somewhere during q800_machine_init() +Steps to reproduce: +1. .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang +2. make qemu-system-m68k +3. ./qemu-system-m68k -M q800 diff --git a/results/classifier/gemma3:12b/device/268 b/results/classifier/gemma3:12b/device/268 new file mode 100644 index 000000000..799e8e95a --- /dev/null +++ b/results/classifier/gemma3:12b/device/268 @@ -0,0 +1,2 @@ + +arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N") diff --git a/results/classifier/gemma3:12b/device/2694 b/results/classifier/gemma3:12b/device/2694 new file mode 100644 index 000000000..caefde121 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2694 @@ -0,0 +1,25 @@ + +error: implicit declaration of function 'IOMainPort' is invalid in C99 +Description of problem: +Build in MacOS + Hardware Overview: + + Model Name: MacBook Air + Chip: Apple M1 + Total Number of Cores: 8 (4 performance and 4 efficiency) + Memory: 16 GB +Steps to reproduce: +1. ./configure --cpu=aarch64 --target-list=aarch64-softmmu --enable-slirp +2. make -j +Additional information: +``` +FAILED: libblock.a.p/block_file-posix.c.o +cc -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/opt/homebrew/opt/zstd/include -I/opt/homebrew/Cellar/glib/2.82.2/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.82.2/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.44/include -I/opt/homebrew/Cellar/glib/2.82.2/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/august/qemu/src -iquote /Users/august/qemu/src/include -iquote /Users/august/qemu/src/host/include/aarch64 -iquote /Users/august/qemu/src/host/include/generic -iquote /Users/august/qemu/src/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c +../block/file-posix.c:3940:18: error: implicit declaration of function 'IOMainPort' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + kernResult = IOMainPort(MACH_PORT_NULL, &mainPort); + ^ +1 error generated. +ninja: build stopped: subcommand failed. +make[1]: *** [run-ninja] Error 1 +make: *** [build] Error 2 +``` diff --git a/results/classifier/gemma3:12b/device/2695 b/results/classifier/gemma3:12b/device/2695 new file mode 100644 index 000000000..00d169469 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2695 @@ -0,0 +1,4 @@ + +how to onboard fw_cfg to other machines +Additional information: +Would it be doable for other machines actually? I didn't dig deeper into this device to understand, but I guess it is connected to the VM somehow and it has some memory mapped to the OS? diff --git a/results/classifier/gemma3:12b/device/270 b/results/classifier/gemma3:12b/device/270 new file mode 100644 index 000000000..c33db0238 --- /dev/null +++ b/results/classifier/gemma3:12b/device/270 @@ -0,0 +1,2 @@ + +virtio only support packed ring size power of 2 diff --git a/results/classifier/gemma3:12b/device/2701 b/results/classifier/gemma3:12b/device/2701 new file mode 100644 index 000000000..c4886e658 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2701 @@ -0,0 +1,2 @@ + +VGPU migration under VFIO. nvidia-vgpu-mgr: Error saving page in pipelined mode on 550.90.05 driver (Debian12,libvirt 10.5.0 qemu 9.1.1) diff --git a/results/classifier/gemma3:12b/device/2714 b/results/classifier/gemma3:12b/device/2714 new file mode 100644 index 000000000..8d1cf46d6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2717 b/results/classifier/gemma3:12b/device/2717 new file mode 100644 index 000000000..9ed7bb992 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2717 @@ -0,0 +1,13 @@ + +semihosting link to risc-v details in document is changed +Description of problem: + +Steps to reproduce: +1. Open https://gitlab.com/qemu-project/qemu/-/blob/master/docs/about/emulation.rst +2. Goto Supported Targets section +3. Click RISC-V link in the table +4. Got 404 + +New url looks like https://github.com/riscv-non-isa/riscv-semihosting/blob/main/riscv-semihosting.adoc +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2718 b/results/classifier/gemma3:12b/device/2718 new file mode 100644 index 000000000..8346a96cd --- /dev/null +++ b/results/classifier/gemma3:12b/device/2718 @@ -0,0 +1,103 @@ + +9.2.0 build failure: FAILED: libcommon.a.p/hw_intc_arm_gicv3_its.c.o +Description of problem: +Unable to build 9.2.0 via our docker container based builder inside a ChromeOS M97 based Docker container (using glibc 2.32). +Steps to reproduce: +1. See build logs. (I thought this was a vte issue, but libvte is the current version, `0.78.2`.) +Additional information: +``` +FAILED: libcommon.a.p/hw_intc_arm_gicv3_its.c.o +cc -m64 -Ilibcommon.a.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Isubprojects/libvduse -I../subprojects/libvduse -I/usr/local/include/p11-kit-1 -I/usr/local/include/pixman-1 -I/usr/local/include/libpng16 -I/usr/local/include/libusb-1.0 -I/usr/local/include/SDL2 -I/usr/local/include/libmount -I/usr/local/include/blkid -I/usr/local/include/glib-2.0 -I/usr/local/lib64/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/ncursesw -I/usr/local/include/gtk-3.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib64/dbus-1.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/fribidi -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/freetype2 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/webp -I/usr/local/include/vte-2.91 -I/usr/local/include/pipewire-0.3 -I/usr/local/include/spa-0.2 -flto=auto -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem /usr/local/tmp/crew/qemu.20241211185452.dir/linux-headers -isystem linux-headers -iquote . -iquote /usr/local/tmp/crew/qemu.20241211185452.dir -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/include -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/host/include/x86_64 -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/host/include/generic -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -O3 -pipe -ffat-lto-objects -fPIC -fuse-ld=mold -flto=auto -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.a.p/hw_intc_arm_gicv3_its.c.o -MF libcommon.a.p/hw_intc_arm_gicv3_its.c.o.d -o libcommon.a.p/hw_intc_arm_gicv3_its.c.o -c ../hw/intc/arm_gicv3_its.c +In file included from ../hw/intc/trace.h:1, + from ../hw/intc/arm_gicv3_its.c:16: +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_vmapti’ at ../hw/intc/arm_gicv3_its.c:680:9: +../hw/intc/trace-events:222:13: error: ‘dte.ittaddr’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_vmapti’: +../hw/intc/arm_gicv3_its.c:654:13: note: ‘dte.ittaddr’ was declared here + 654 | DTEntry dte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_vmapti’ at ../hw/intc/arm_gicv3_its.c:680:9: +../hw/intc/trace-events:222:13: error: ‘dte.size’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_vmapti’: +../hw/intc/arm_gicv3_its.c:654:13: note: ‘dte.size’ was declared here + 654 | DTEntry dte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_mapti’ at ../hw/intc/arm_gicv3_its.c:608:9: +../hw/intc/trace-events:222:13: error: ‘dte.ittaddr’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_mapti’: +../hw/intc/arm_gicv3_its.c:586:13: note: ‘dte.ittaddr’ was declared here + 586 | DTEntry dte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_mapti’ at ../hw/intc/arm_gicv3_its.c:608:9: +../hw/intc/trace-events:222:13: error: ‘dte.size’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_mapti’: +../hw/intc/arm_gicv3_its.c:586:13: note: ‘dte.size’ was declared here + 586 | DTEntry dte; + | ^~~ +In function ‘lookup_vte’, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1036:14: +../hw/intc/arm_gicv3_its.c:459:8: error: ‘vte.rdbase’ may be used uninitialized [-Werror=maybe-uninitialized] + 459 | if (vte->rdbase >= s->gicv3->num_cpu) { + | ^ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.rdbase’ was declared here + 1033 | VTEntry vte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_vte_write’, + inlined from ‘trace_gicv3_its_vte_write’ at trace/trace-hw_intc.h:6789:9, + inlined from ‘update_vte’ at ../hw/intc/arm_gicv3_its.c:944:5, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1051:10: +../hw/intc/trace-events:227:13: error: ‘vte.vptaddr’ may be used uninitialized [-Werror=maybe-uninitialized] + 227 | gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x" + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.vptaddr’ was declared here + 1033 | VTEntry vte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_vte_write’, + inlined from ‘trace_gicv3_its_vte_write’ at trace/trace-hw_intc.h:6789:9, + inlined from ‘update_vte’ at ../hw/intc/arm_gicv3_its.c:944:5, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1051:10: +../hw/intc/trace-events:227:13: error: ‘vte.vptsize’ may be used uninitialized [-Werror=maybe-uninitialized] + 227 | gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x" + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.vptsize’ was declared here + 1033 | VTEntry vte; + | ^~~ +In function ‘lookup_vte’, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1036:14: +../hw/intc/arm_gicv3_its.c:453:13: error: ‘MEM <unsigned char> [(struct VTEntry *)&vte]’ may be used uninitialized [-Werror=maybe-uninitialized] + 453 | if (!vte->valid) { + | ~~~^~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘MEM <unsigned char> [(struct VTEntry *)&vte]’ was declared here + 1033 | VTEntry vte; + | ^~~ +cc1: all warnings being treated as errors + +``` + +Full Build log: + +[qemu-build-log.zip](/uploads/db227e4a6bbbcfccd0e1e3ccaacf1aec/qemu-build-log.zip) diff --git a/results/classifier/gemma3:12b/device/272 b/results/classifier/gemma3:12b/device/272 new file mode 100644 index 000000000..a022fdd51 --- /dev/null +++ b/results/classifier/gemma3:12b/device/272 @@ -0,0 +1,2 @@ + +QEMU: block/vvfat driver issues diff --git a/results/classifier/gemma3:12b/device/2722 b/results/classifier/gemma3:12b/device/2722 new file mode 100644 index 000000000..cdca55c21 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2722 @@ -0,0 +1,49 @@ + +TLB Invalidation time out on i915 SR-IOV passthrough +Description of problem: +Hello, + +I tried to use SR-IOV on i915 driver freshly available on the [LTS intel kernel](https://github.com/intel/linux-intel-lts) with this [kernel version ](https://github.com/intel/linux-intel-lts/tree/lts-v6.6.34-linux-240626T131354Z) for pci passthrough purpose. +After setting up SR-IOV (kernel compilation, kernel cmdline, vfio-pci driver attribution to the new pci..) + I've got my two new pci. + +``` +00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +DeviceName: Onboard IGD + +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: i915 + +00:02.1 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: vfio-pci + +00:02.2 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: vfio-pci +``` +I gave one of those pci to my VM with this qemu cmdline: +``` +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-passthrough,hv-vendor-id=IrisXE +... +-device vfio-pci-nohotplug,host=0000:00:02.1,id=hostdev0,bus=pci.4,addr=0x0 +``` +Sometimes it working properly when I start the qemu cmdline but most of the time I've got those kernel errors and a GPU hang: +``` + kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + .... + kernel Fence expiration time out i915-0000:00:02.0:renderThread22381:6e0! + kernel i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.13.1 + kernel i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 + kernel i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads + kernel i915 0000:00:02.0: [drm] GT0: GUC: submission enabled + kernel i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled + kernel [ 2730.991019] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dfbfff, in renderThread [22381] + kernel [ 2730.991084] i915 0000:00:02.0: [drm] renderThread22381 context reset due to GPU hang +``` +It mostly appears when Qemu is starting.. + +Any help would be appreciate, thanks a lot diff --git a/results/classifier/gemma3:12b/device/273 b/results/classifier/gemma3:12b/device/273 new file mode 100644 index 000000000..87e259188 --- /dev/null +++ b/results/classifier/gemma3:12b/device/273 @@ -0,0 +1,2 @@ + +xhci_find_stream: Assertion `streamid != 0' failed. diff --git a/results/classifier/gemma3:12b/device/2732 b/results/classifier/gemma3:12b/device/2732 new file mode 100644 index 000000000..1e08947ff --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2733 b/results/classifier/gemma3:12b/device/2733 new file mode 100644 index 000000000..c442c0d11 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2733 @@ -0,0 +1,13 @@ + +-machine raspi4b won't dump dtb +Description of problem: +the raspi4b machine won't dump tdb +Steps to reproduce: +``` +$ qemu-system-aarch64 -machine virt -machine dumpdtb=p.dmp +qemu-system-aarch64: info: dtb dumped to p.dmp. Exiting. +$ qemu-system-aarch64 -machine raspi4b -machine dumpdtb=p.dmp +``` +notice no dtb is dumped for the raspi4b machine +Additional information: +see also https://gitlab.com/qemu-project/qemu/-/issues/2729 diff --git a/results/classifier/gemma3:12b/device/2734 b/results/classifier/gemma3:12b/device/2734 new file mode 100644 index 000000000..c744c6099 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2734 @@ -0,0 +1,25 @@ + +many aarch64 machines exit with "fatal: Lockup: can't escalate 3 to HardFault" +Description of problem: +`-machine netduino2` and `-machine microbit` and many others dump core +Steps to reproduce: +``` +qemu-system-aarch64 -machine netduino2 +qemu-system-aarch64 -machine microbit +... +$ for x in microbit netduino2 b-l475e-iot01a emcraft-sf2 fby35-bmc lm3s6965evb lm3s811evb musca-a musca-b1 netduinoplus2 olimex-stm32-h405 stm32vldiscovery +do qemu-system-aarch64 -machine $x +done +``` +and all the `mps2-*` machines all result in +``` +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) + +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000 +XPSR=40000003 -Z-- A handler +FPSCR: 00000000 +Aborted (core dumped) +``` diff --git a/results/classifier/gemma3:12b/device/2735 b/results/classifier/gemma3:12b/device/2735 new file mode 100644 index 000000000..c2c106c3b --- /dev/null +++ b/results/classifier/gemma3:12b/device/2735 @@ -0,0 +1,11 @@ + +Couldn't find rom image 'canon-a1100-rom1.bin'. +Description of problem: +``` +$ qemu-system-aarch64 -machine canon-a1100 +qemu-system-aarch64: Couldn't find rom image 'canon-a1100-rom1.bin'. +``` +Steps to reproduce: +``` +qemu-system-aarch64 -machine canon-a1100 +``` diff --git a/results/classifier/gemma3:12b/device/274 b/results/classifier/gemma3:12b/device/274 new file mode 100644 index 000000000..71ecb8b8c --- /dev/null +++ b/results/classifier/gemma3:12b/device/274 @@ -0,0 +1,2 @@ + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps diff --git a/results/classifier/gemma3:12b/device/2746 b/results/classifier/gemma3:12b/device/2746 new file mode 100644 index 000000000..69decbcf6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2746 @@ -0,0 +1,2 @@ + +NO_CAST.INTEGER_OVERFLOW in /hw/net/e1000.c diff --git a/results/classifier/gemma3:12b/device/2753 b/results/classifier/gemma3:12b/device/2753 new file mode 100644 index 000000000..c4ee1bf2e --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2758 b/results/classifier/gemma3:12b/device/2758 new file mode 100644 index 000000000..f30e05621 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2758 @@ -0,0 +1,24 @@ + +Out-of-bounds access smc91c111_readb() +Description of problem: +An out-of-bounds bug was triggered by my fuzzer. + +It looks like the code doesn't have boundary checks for `data`'s access. + +The error is `hw/net/smc91c111.c:605:24: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')` + +It's likely that the line 457 also needs a check. +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +writew 0x4e00000c 0x46084a4a +writel 0x4e00000c 0x5c022fcc +clock_step +writel 0x4e000004 0x2fffa1b1 +clock_step +readl 0x4e000008 +EOF +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2759 b/results/classifier/gemma3:12b/device/2759 new file mode 100644 index 000000000..a2d2431d9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2759 @@ -0,0 +1,2 @@ + +hw/usb/redirect.c: usbredir_buffered_bulk_packet() may leak memory (or worse) diff --git a/results/classifier/gemma3:12b/device/2768 b/results/classifier/gemma3:12b/device/2768 new file mode 100644 index 000000000..96df7e120 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2768 @@ -0,0 +1,17 @@ + +PowerPC e200 duplicate register definitions +Description of problem: +Registers DSRR0 and DSRR1 defined twice in the `target/ppc/cpu_init.c`: + +- in the common [`register_BookE_sprs()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L740-748) +- and specific [`init_proc_e200()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L2735-2742) + +The second case should be removed. +Steps to reproduce: +1. run `qemu-system-ppc -cpu e200z5` +2. check output +``` +** +ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0)) +Bail out! ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0)) +``` diff --git a/results/classifier/gemma3:12b/device/2771 b/results/classifier/gemma3:12b/device/2771 new file mode 100644 index 000000000..d5171a4d1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2771 @@ -0,0 +1,2 @@ + +qemu-system-x86_64: ../block/block-backend.c:1290: blk_in_drain: Assertion `qemu_in_main_thread()' failed. diff --git a/results/classifier/gemma3:12b/device/2774 b/results/classifier/gemma3:12b/device/2774 new file mode 100644 index 000000000..b275016ff --- /dev/null +++ b/results/classifier/gemma3:12b/device/2774 @@ -0,0 +1,4 @@ + +Consider adding an `aliases` node to RISC-V DTB that includes `serial0` alias +Additional information: +Example of an [aliases section for physical SoC](https://github.com/torvalds/linux/blob/b62cef9a5c673f1b8083159f5dc03c1c5daced2f/arch/riscv/boot/dts/sophgo/cv1800b-milkv-duo.dts#L14-L20). diff --git a/results/classifier/gemma3:12b/device/2776 b/results/classifier/gemma3:12b/device/2776 new file mode 100644 index 000000000..8e1dc3e66 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2776 @@ -0,0 +1,2 @@ + +OHCI: Incorrectly reports an overrun error diff --git a/results/classifier/gemma3:12b/device/2777 b/results/classifier/gemma3:12b/device/2777 new file mode 100644 index 000000000..d39ddb68e --- /dev/null +++ b/results/classifier/gemma3:12b/device/2777 @@ -0,0 +1,60 @@ + +Assert failure in ahci-hd device +Description of problem: +Assert + +``` +qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed. +``` +can be triggered with some qtest commands. This was found by fuzzing. +Steps to reproduce: +Command: + +``` +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 ide-hd,drive=disk0 -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0x0 0x1 0x27 +write 0x1 0x1 0x80 +write 0x2 0x1 0x25 +write 0xe00003b8 0x1 0x02 +write 0xe0000398 0x1 0x01 +EOF +``` + +Results in + +``` +[I 0.000001] OPENED +[R +0.076075] outl 0xcf8 0x8000fa24 +[S +0.076165] OK +OK +[R +0.076198] outl 0xcfc 0xe0000000 +[S +0.076242] OK +OK +[R +0.076320] outl 0xcf8 0x8000fa04 +[S +0.076344] OK +OK +[R +0.076379] outw 0xcfc 0x06 +[S +0.077676] OK +OK +[R +0.077760] write 0x0 0x1 0x27 +[S +0.079429] OK +OK +[R +0.079552] write 0x1 0x1 0x80 +[S +0.079592] OK +OK +[R +0.079618] write 0x2 0x1 0x25 +[S +0.079645] OK +OK +[R +0.079669] write 0xe00003b8 0x1 0x02 +[S +0.079709] OK +OK +[R +0.079733] write 0xe0000398 0x1 0x01 +qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed. +Aborted +``` +Additional information: +Maybe we can just `goto eot;` instead of assert? diff --git a/results/classifier/gemma3:12b/device/2778 b/results/classifier/gemma3:12b/device/2778 new file mode 100644 index 000000000..3f0154951 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2778 @@ -0,0 +1,100 @@ + +Null Dereference in ahci-hd device +Description of problem: +Issue was found by fuzzing. With some qtest commands we can crash qemu-system-x86_64 because of Null dereference. +Steps to reproduce: +Command: + +``` +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 ide-hd,drive=disk0 -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0xe00003b8 0x1 0x01 +write 0x0 0x1 0x27 +write 0x1 0x1 0x80 +write 0x2 0x1 0x20 +write 0x7 0x1 0x01 +write 0xe0000398 0x1 0x01 +write 0xe0000398 0x1 0x00 +write 0xe0000398 0x1 0x01 +EOF +``` + +Results in + +``` +[I 0.000001] OPENED +[R +0.082978] outl 0xcf8 0x8000fa24 +[S +0.083040] OK +OK +[R +0.083070] outl 0xcfc 0xe0000000 +[S +0.083115] OK +OK +[R +0.083132] outl 0xcf8 0x8000fa04 +[S +0.083152] OK +OK +[R +0.083180] outw 0xcfc 0x06 +[S +0.084233] OK +OK +[R +0.084291] write 0xe00003b8 0x1 0x01 +[S +0.084344] OK +OK +[R +0.084384] write 0x0 0x1 0x27 +[S +0.085007] OK +OK +[R +0.085041] write 0x1 0x1 0x80 +[S +0.085055] OK +OK +[R +0.085071] write 0x2 0x1 0x20 +[S +0.085084] OK +OK +[R +0.085096] write 0x7 0x1 0x01 +[S +0.085110] OK +OK +[R +0.085123] write 0xe0000398 0x1 0x01 +[S +0.085254] OK +OK +[R +0.085294] write 0xe0000398 0x1 0x00 +[S +0.085324] OK +OK +[R +0.085349] write 0xe0000398 0x1 0x01 +[S +0.085408] OK +OK +../hw/ide/ahci.c:1377:46: runtime error: member access within null pointer of type 'AHCICmdHdr' (aka 'struct AHCICmdHdr') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1377:46 in +../hw/ide/ahci.c:1377:46: runtime error: load of null pointer of type 'uint16_t' (aka 'unsigned short') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1377:46 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==2547739==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55abf3a79f9c bp 0x7ffc213000d0 sp 0x7ffc212fffa0 T0) +==2547739==The signal is caused by a READ memory access. +==2547739==Hint: address points to the zero page. + #0 0x55abf3a79f9c in ahci_pio_transfer /home/artemiin/Work/original_qemu/build/../hw/ide/ahci.c:1377:46 + #1 0x55abf3a8a396 in ide_transfer_start_norecurse /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:581:5 + #2 0x55abf3aab79e in ide_transfer_start /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:588:9 + #3 0x55abf3aab79e in ide_sector_read_cb /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:789:5 + #4 0x55abf3a8d6e2 in ide_buffered_readv_cb /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:684:9 + #5 0x55abf4f31d33 in blk_aio_complete /home/artemiin/Work/original_qemu/build/../block/block-backend.c:1552:9 + #6 0x55abf545010b in aio_bh_call /home/artemiin/Work/original_qemu/build/../util/async.c:172:5 + #7 0x55abf545089f in aio_bh_poll /home/artemiin/Work/original_qemu/build/../util/async.c:219:13 + #8 0x55abf53e746a in aio_dispatch /home/artemiin/Work/original_qemu/build/../util/aio-posix.c:424:5 + #9 0x55abf545469a in aio_ctx_dispatch /home/artemiin/Work/original_qemu/build/../util/async.c:361:5 + #10 0x7f358845b7a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4) + #11 0x55abf5455787 in glib_pollfds_poll /home/artemiin/Work/original_qemu/build/../util/main-loop.c:287:9 + #12 0x55abf5455787 in os_host_main_loop_wait /home/artemiin/Work/original_qemu/build/../util/main-loop.c:310:5 + #13 0x55abf5455787 in main_loop_wait /home/artemiin/Work/original_qemu/build/../util/main-loop.c:589:11 + #14 0x55abf425c296 in qemu_main_loop /home/artemiin/Work/original_qemu/build/../system/runstate.c:835:9 + #15 0x55abf51df1c6 in qemu_default_main /home/artemiin/Work/original_qemu/build/../system/main.c:48:14 + #16 0x55abf51df1a1 in main /home/artemiin/Work/original_qemu/build/../system/main.c:76:9 + #17 0x7f3587219249 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #18 0x7f3587219304 in __libc_start_main csu/../csu/libc-start.c:360:3 + #19 0x55abf353be60 in _start (/home/artemiin/Work/original_qemu/build/qemu-system-x86_64+0x1828e60) (BuildId: f91712a3af40a999ce35e39809ce00f92c35ae25) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/artemiin/Work/original_qemu/build/../hw/ide/ahci.c:1377:46 in ahci_pio_transfer +==2547739==ABORTING +``` +Additional information: +This issue may need a complicated patch so I ask developers to take a look at this issue. diff --git a/results/classifier/gemma3:12b/device/2779 b/results/classifier/gemma3:12b/device/2779 new file mode 100644 index 000000000..ab6cac739 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2779 @@ -0,0 +1,42 @@ + +Segmentation fault when introspecting machine properties +Description of problem: +QEMU currrently crashes when trying to list the properties of the q35 machine type while QEMU has been started with the i440fx machine type. Introspecting QOM objects for their properties should always be possible, but apparently there is currently something causing a crash in this case. +Steps to reproduce: +1. Start QEMU with: qemu-system-x86_64 -M pc -qmp stdio +2. Enter these commands in the QMP monitor: + +``` + { "execute": "qmp_capabilities" } + { "execute": "qom-list-properties","arguments": { "typename": "pc-q35-10.0-machine"}} +``` +Additional information: +Backtrace looks like this: +``` +mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +738 s->cmos_data[addr] = val; +--Type <RET> for more, q to quit, c to continue without paging--#0 mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +#1 0x0000555555bf15d2 in pc_machine_done (notifier=0x555557f40750, data=<optimized out>) at ../../devel/qemu/hw/i386/pc.c:632 +#2 0x0000555555d4f7a2 in object_init_with_type (obj=obj@entry=0x555557f40320, ti=ti@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:424 +#3 0x0000555555d49c7e in object_initialize_with_type (obj=0x555557f40320, size=<optimized out>, type=type@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:570 +#4 0x0000555555d4a660 in object_new_with_type (type=0x5555579c3c60) at ../../devel/qemu/qom/object.c:774 +#5 object_new (typename=typename@entry=0x555558672b30 "pc-q35-10.0-machine") at ../../devel/qemu/qom/object.c:789 +#6 0x0000555555e825c5 in qmp_qom_list_properties (typename=0x555558672b30 "pc-q35-10.0-machine", errp=errp@entry=0x7fffffffd988) + at ../../devel/qemu/qom/qom-qmp-cmds.c:205 +#7 0x0000555555ef0525 in qmp_marshal_qom_list_properties (args=<optimized out>, ret=0x7fffeda9af00, errp=0x7fffeda9af08) + at qapi/qapi-commands-qom.c:288 +#8 0x0000555555f1edc1 in do_qmp_dispatch_bh (opaque=0x7fffeda9aed0) at ../../devel/qemu/qapi/qmp-dispatch.c:128 +#9 0x0000555555f40e28 in aio_bh_poll (ctx=ctx@entry=0x5555579f2930) at ../../devel/qemu/util/async.c:219 +#10 0x0000555555f2886f in aio_dispatch (ctx=0x5555579f2930) at ../../devel/qemu/util/aio-posix.c:424 +#11 0x0000555555f41cbb in aio_ctx_dispatch (source=0x0, callback=0x5f, user_data=<optimized out>) at ../../devel/qemu/util/async.c:361 +#12 0x00007ffff6d98e8c in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0 +#13 0x00007ffff6d99155 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#14 0x0000555555f42540 in glib_pollfds_poll () at ../../devel/qemu/util/main-loop.c:287 +#15 os_host_main_loop_wait (timeout=<optimized out>) at ../../devel/qemu/util/main-loop.c:310 +#16 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../devel/qemu/util/main-loop.c:589 +#17 0x0000555555ae1207 in qemu_main_loop () at ../../devel/qemu/system/runstate.c:835 +#18 0x0000555555e85d57 in qemu_default_main (opaque=<optimized out>) at ../../devel/qemu/system/main.c:48 +#19 0x0000555555e85d2f in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:76 +``` diff --git a/results/classifier/gemma3:12b/device/278 b/results/classifier/gemma3:12b/device/278 new file mode 100644 index 000000000..541327844 --- /dev/null +++ b/results/classifier/gemma3:12b/device/278 @@ -0,0 +1,2 @@ + +jack audio dev produces no sound diff --git a/results/classifier/gemma3:12b/device/2780 b/results/classifier/gemma3:12b/device/2780 new file mode 100644 index 000000000..6768f90cf --- /dev/null +++ b/results/classifier/gemma3:12b/device/2780 @@ -0,0 +1,18 @@ + +Out-of-bounds access in smc91c111_receive() +Description of problem: +An out-of-bounds access happens at hw/net/smc91c111.c:705. + +`hw/net/smc91c111.c:705:5: runtime error: index -1 out of bounds for type 'int[4]'` +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +writew 0x4e000005 0x227 +writel 0x4e00000b 0x25ab1f2 +writew 0x4e000000 0xaa6c +clock_step +EOF +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2792 b/results/classifier/gemma3:12b/device/2792 new file mode 100644 index 000000000..02410c62c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2792 @@ -0,0 +1,71 @@ + +qemu-system-aarch64 segfault at startup with --enable-rust +Description of problem: +The following commit breaks type class initialization for `pl011_luminary`: + +``` +d9434f29ca83e114fe02ed24c8ad2ccfa7ac3fe9 is the first bad commit +commit d9434f29ca83e114fe02ed24c8ad2ccfa7ac3fe9 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Fri Nov 29 11:38:59 2024 +0100 + + rust: qom: move device_id to PL011 class side + + There is no need to monkeypatch DeviceId::Luminary into the already-initialized + PL011State. Instead, now that we can define a class hierarchy, we can define + PL011Class and make device_id a field in there. + + There is also no need anymore to have "Arm" as zero, so change DeviceId into a + wrapper for the array; all it does is provide an Index<hwaddr> implementation + because arrays can only be indexed by usize. + + Reviewed-by: Zhao Liu <zhao1.liu@intel.com> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + rust/hw/char/pl011/src/device.rs | 59 +++++++++++++++++++--------------------- + 1 file changed, 28 insertions(+), 31 deletions(-) +bisect found first bad commit +``` + +It results in a segmentation fault during type initialization at startup: + +``` +$ ./build/qemu-system-aarch64 -machine help +zsh: segmentation fault (core dumped) ./build/qemu-system-aarch64 -machine help +``` + +Because the class is uninitialized on the `pl011_luminary` TypeInfo (I think): + +``` +$ gdb --args ./build/qemu-system-aarch64 -machine help +... +Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. +0x0000555555fc0fcf in object_class_dynamic_cast (class=class@entry=0x5555575ca128, typename=typename@entry=0x5555562650cd "resettable") at ../qom/object.c:966 +966 if (type->class->interfaces && +(gdb) p type->class +$1 = (ObjectClass *) 0x0 +(gdb) bt +#0 0x0000555555fc0fcf in object_class_dynamic_cast (class=class@entry=0x5555575ca128, typename=typename@entry=0x5555562650cd "resettable") at ../qom/object.c:966 +#1 0x0000555555fc1473 in object_class_dynamic_cast_assert (class=class@entry=0x5555575ca128, typename=typename@entry=0x5555562650cd "resettable", + file=file@entry=0x5555562651a0 "/home/pdel/qemu/include/hw/resettable.h", line=line@entry=21, func=func@entry=0x55555643d2b0 <__func__.13> "RESETTABLE_CLASS") at ../qom/object.c:1016 +#2 0x0000555555fbc61b in RESETTABLE_CLASS (klass=0x5555575ca128) at /home/pdel/qemu/include/hw/resettable.h:21 +#3 device_class_set_legacy_reset (dc=0x5555575ca128, dev_reset=0x5555560dacb0 <qemu_api::qdev::rust_reset_fn>) at ../hw/core/qdev.c:790 +#4 0x00005555560dac03 in qemu_api::qdev::<impl qemu_api::qom::ClassInitImpl<qemu_api::bindings::DeviceClass> for T>::class_init (dc=0x5555575ca128) + at rust/qemu-api/libqemu_api.rlib.p/structured/qdev.rs:84 +#5 qemu_api::sysbus::<impl qemu_api::qom::ClassInitImpl<qemu_api::bindings::SysBusDeviceClass> for T>::class_init (sdc=0x5555575ca128) at rust/qemu-api/libqemu_api.rlib.p/structured/sysbus.rs:31 +#6 <pl011::device::PL011State as qemu_api::qom::ClassInitImpl<pl011::device::PL011Class>>::class_init (klass=0x5555575ca120) at ../rust/hw/char/pl011/src/device.rs:140 +#7 qemu_api::qom::rust_class_init (klass=0x5555575ca120, _data=<optimized out>) at rust/qemu-api/libqemu_api.rlib.p/structured/qom.rs:176 +#8 0x0000555555fc0930 in type_initialize (ti=0x555557555eb0) at ../qom/object.c:359 +#9 type_initialize (ti=ti@entry=0x555557556070) at ../qom/object.c:365 +#10 0x0000555555fc1190 in type_initialize (ti=0x555557556070) at ../qom/object.c:1122 +#11 object_class_foreach_tramp (key=<optimized out>, value=0x555557556070, opaque=0x7fffffffdd00) at ../qom/object.c:1110 +#12 0x00007ffff7528668 in g_hash_table_foreach () from /lib64/libglib-2.0.so.0 +#13 0x0000555555fc1931 in object_class_foreach (opaque=0x7fffffffdcf8, include_abstract=false, implements_type=<optimized out>, fn=0x555555fbf810 <object_class_get_list_tramp>) at ../qom/object.c:87 +#14 object_class_get_list (implements_type=implements_type@entry=0x5555562c5440 "machine", include_abstract=include_abstract@entry=false) at ../qom/object.c:1189 +#15 0x0000555555bf53ac in machine_help_func (qdict=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../system/vl.c:1559 +#16 qemu_init (argc=3, argv=<optimized out>) at ../system/vl.c:3319 +#17 0x00005555558f1a89 in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:68 +``` +Steps to reproduce: +1. Checkout cf86770c7aa31ebd6e56f4eeb25c34107f92c51e +2. `./configure --target-list=aarch64-softmmu --enable-rust && ninja -C build && ./build/qemu-system-aarch64 -machine help` diff --git a/results/classifier/gemma3:12b/device/2805 b/results/classifier/gemma3:12b/device/2805 new file mode 100644 index 000000000..4d15b9aa9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2806 b/results/classifier/gemma3:12b/device/2806 new file mode 100644 index 000000000..47cd92503 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2806 @@ -0,0 +1,10 @@ + +Build from source failed on Arch Linux with target-list=arm-softmmu,arm-linux-user +Description of problem: +When I tried to build the latest QEMU version, the build process top at 'linking test-qos' +Steps to reproduce: +1. Clone the latest git version of QEMU +2. Configure --target-list=arm-softmmu,arm-linux-user +3. Make +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2808 b/results/classifier/gemma3:12b/device/2808 new file mode 100644 index 000000000..e2b80a5ee --- /dev/null +++ b/results/classifier/gemma3:12b/device/2808 @@ -0,0 +1,2 @@ + +Links to the RISC-V IOMMU Architecture Specification are broken in the docs diff --git a/results/classifier/gemma3:12b/device/2809 b/results/classifier/gemma3:12b/device/2809 new file mode 100644 index 000000000..51a8ece9a --- /dev/null +++ b/results/classifier/gemma3:12b/device/2809 @@ -0,0 +1,12 @@ + +Data races in TestBlockJob fields in test-block-iothread +Description of problem: +A data race in the access of `TestBlockJob` fields in `tests/unit/test-block-iothread.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-block-iothread +MALLOC_PERTURB_=67 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-block-iothread --tap -k +``` diff --git a/results/classifier/gemma3:12b/device/2812 b/results/classifier/gemma3:12b/device/2812 new file mode 100644 index 000000000..a473720dd --- /dev/null +++ b/results/classifier/gemma3:12b/device/2812 @@ -0,0 +1,2 @@ + +Crash initializing audio device diff --git a/results/classifier/gemma3:12b/device/2826 b/results/classifier/gemma3:12b/device/2826 new file mode 100644 index 000000000..e57cb4908 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2826 @@ -0,0 +1,10 @@ + +The host PCI bridge disappeared on the big endian MIPS Malta machine +Description of problem: +The tests/avocado/linux_ssh_mips_malta.py test currently fails for the big endian machines. It tries to check for the PCI host bridge with ``lspci -d 11ab:4620``, but that does not show the expected output anymore -- it looks like the host bridge cannot be correctly discovered by the guest Linux kernel anymore. +Steps to reproduce: +1. Get the kernel and disk image from https://people.debian.org/~aurel32/qemu/mips/ +2. Boot the guest as described above. +3. lspci -d 11ab:4620 +Additional information: +This used to work fine before commit 145e2198d749ec09a405f1607a9932499b76f1eb , so this rework likely introduced the bug. Looking at the code that got removed there, I could see an additional check ``phb->config_reg & 0x00fff800`` that is not present in the new code anymore, so the space for the host bridge itself likely should not get swapped. Reverting 3d85c7c15fc7ce986cf1a8e73da1217228f35685 and 145e2198d749ec09a405f1607a9932499b76f1eb seems to fix the problem (at least on little endian hosts). diff --git a/results/classifier/gemma3:12b/device/2843 b/results/classifier/gemma3:12b/device/2843 new file mode 100644 index 000000000..34530f0a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2845 b/results/classifier/gemma3:12b/device/2845 new file mode 100644 index 000000000..d3a69f831 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2856 b/results/classifier/gemma3:12b/device/2856 new file mode 100644 index 000000000..8425b0936 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2856 @@ -0,0 +1,91 @@ + +segfault when passing x-vga=on on gpu(old) passthrough +Description of problem: +When using x-vga=on on the ati x550 gpu passthrough, qemu-system-x86 segfault occurs.(I think it may happen with other ati cards from same era, ati x300, ati x600, ati x800) +Similar bug from 2017 on nvidia 7300GS: +https://bugs.launchpad.net/qemu/+bug/1678466 +Additional information: +``` +dmesg: +[ 5050.113978] qemu-system-x86[8288]: segfault at b8 ip 000055c4f459ad47 sp 00007fff81f966e0 error 4 in qemu-system-x86_64[57ed47,55c +4f418f000+69f000] likely on CPU 11 (core 20, socket 0) +[ 5050.113987] Code: c0 75 f0 48 8b 6b 60 48 89 b3 80 00 00 00 67 e8 9f 82 00 00 48 8b 7b 40 83 05 b0 11 2e 01 01 48 85 ff 74 06 67 e +8 59 1e 08 00 <48> 8b 85 b8 00 00 00 48 85 c0 74 7d 8b 93 b0 00 00 00 eb 11 0f 1f +[ 5050.272446] vfio-pci 0000:07:00.0: Refused to change power state from D0 to D3hot +``` +``` +lspci -vv: +07: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 3 + IOMMU group: 18 + Region 0: Memory at 54000000 (32-bit, prefetchable) [disabled] [size=64M] + Region 1: I/O ports at 3000 [disabled] [size=256] + Region 2: Memory at 59c30000 (32-bit, non-prefetchable) [disabled] [size=64K] + Expansion ROM at 59c00000 [disabled] [size=128K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Express (v1) Endpoint, IntMsgNum 0 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 10W TEE-IO- + DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+ + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- 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, LnkDisable- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x1 (downgraded) + 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- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr- + PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- + ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr- + PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- + UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ + ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr- + PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF- + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 04000001 0000030f 07070000 7efb9a03 + +07: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- + IOMMU group: 18 + Region 0: Memory at 59c20000 (32-bit, non-prefetchable) [disabled] [size=64K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Express (v1) Endpoint, IntMsgNum 0 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0W TEE-IO- + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- 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, LnkDisable- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x1 (downgraded) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- +``` + +(In win7 when the "07:00.1 Display controller" uses the gpu driver, dmesg spam errors occur and VM functions very very slow. I don't know where to report this, libvirt?. This I tested only in virt-manager. "07:00.1 Display controller" can be disabled in Win7 device manager and problems disappear. Independent if this, booting with x-vga=off image is corrupted on the monitor connected to passthrough gpu until driver is loaded. Image is white with vertical dark stripes.) +``` +[ 3160.598553] DMAR: [INTR-REMAP] Request device [07:00.1] fault index 0x50 [fault reason 0x26] Blocked an interrupt request due to source-id verification failure +[ 3161.098536] DMAR: DRHD: handling fault status reg 2 +[ 3165.098584] dmar_fault: 23 callbacks suppressed +``` diff --git a/results/classifier/gemma3:12b/device/2861 b/results/classifier/gemma3:12b/device/2861 new file mode 100644 index 000000000..db29d569c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2861 @@ -0,0 +1,8 @@ + +hw/pci-host/designware.c incorrect write to DESIGNWARE_PCIE_ATU_UPPER_TARGET register +Description of problem: +I think this is a obvious bug + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/designware.c?ref_type=heads#L374 + +Write to register DESIGNWARE_PCIE_ATU_UPPER_TARGET, val should be shifted left to update upper 32 bit part. diff --git a/results/classifier/gemma3:12b/device/2866 b/results/classifier/gemma3:12b/device/2866 new file mode 100644 index 000000000..862255151 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2873 b/results/classifier/gemma3:12b/device/2873 new file mode 100644 index 000000000..11a0256d5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2873 @@ -0,0 +1,10 @@ + +[chardev] In case of stdin redirection, SYS_READC semihost call will block in the chardev backend when EOF is reached. +Description of problem: +The previous command hangs, EOF is not detected. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/2879 b/results/classifier/gemma3:12b/device/2879 new file mode 100644 index 000000000..d535951af --- /dev/null +++ b/results/classifier/gemma3:12b/device/2879 @@ -0,0 +1,2 @@ + +-smbios type=11,path=xxx results in buffer overrun due to missing null terminator diff --git a/results/classifier/gemma3:12b/device/2898 b/results/classifier/gemma3:12b/device/2898 new file mode 100644 index 000000000..ae1e42d96 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2898 @@ -0,0 +1,116 @@ + +-M virt,dumpdtb is missing information from the device tree +Description of problem: +dumpdtb no longer produces a device tree with the full system described. + + +``` +$ dtc -I dtb -O dts test.dtb +<stdout>: Warning (unit_address_vs_reg): /soc/pci@30000000: node has a unit name, but no reg or ranges property +<stdout>: Warning (simple_bus_reg): /soc/pci@30000000: missing or empty reg/ranges property +/dts-v1/; + +/ { + #address-cells = <0x02>; + #size-cells = <0x02>; + compatible = "riscv-virtio"; + model = "riscv-virtio,qemu"; + + pmu { + riscv,event-to-mhpmcounters = <0x01 0x01 0x7fff9 0x02 0x02 0x7fffc 0x10019 0x10019 0x7fff8 0x1001b 0x1001b 0x7fff8 0x10021 0x10021 0x7fff8>; + compatible = "riscv,pmu"; + }; + + fw-cfg@10100000 { + dma-coherent; + reg = <0x00 0x10100000 0x00 0x18>; + compatible = "qemu,fw-cfg-mmio"; + }; + + flash@20000000 { + bank-width = <0x04>; + reg = <0x00 0x20000000 0x00 0x2000000 0x00 0x22000000 0x00 0x2000000>; + compatible = "cfi-flash"; + }; + + aliases { + }; + + chosen { + rng-seed = <0xd4266784 0xc7a7c66f 0xd5b7347d 0x862188f3 0x78065a8e 0xebdedae5 0xd77c47b0 0x34d31eff>; + }; + + soc { + #address-cells = <0x02>; + #size-cells = <0x02>; + compatible = "simple-bus"; + ranges; + + pci@30000000 { + }; + }; +}; +``` +Steps to reproduce: +1. qemu-system-riscv64 -machine virt,dumpdtb=test.dtb +2. dtc -I dtb -O dts test.dtb +Additional information: +The regression was introduced in https://gitlab.com/qemu-project/qemu/-/commit/8fd2518ef2f8d. If this commit is reverted, the expected behavior returns. + +``` +dtc -I dtb -O dts test.dtb | grep "@" + platform-bus@4000000 { + memory@80000000 { + cpu@0 { + fw-cfg@10100000 { + flash@20000000 { + serial0 = "/soc/serial@10000000"; + stdout-path = "/soc/serial@10000000"; + rtc@101000 { + serial@10000000 { + clock-frequency = "", "8@"; + test@100000 { + virtio_mmio@10008000 { + virtio_mmio@10007000 { + virtio_mmio@10006000 { + virtio_mmio@10005000 { + virtio_mmio@10004000 { + virtio_mmio@10003000 { + virtio_mmio@10002000 { + virtio_mmio@10001000 { + plic@c000000 { + clint@2000000 { + pci@30000000 { +``` + +Other machines are affected to a lesser degree. The arm virt machine: + +qemu-system-arm -machine virt,dumpdtb=test.dtb +``` +@@ -8,28 +8,6 @@ + #address-cells = <0x02>; + compatible = "linux,dummy-virt"; + +- psci { +- migrate = <0x84000005>; +- cpu_on = <0x84000003>; +- cpu_off = <0x84000002>; +- cpu_suspend = <0x84000001>; +- method = "hvc"; +- compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci"; +- }; +- +- memory@40000000 { +- reg = <0x00 0x40000000 0x00 0x8000000>; +- device_type = "memory"; +- }; +- +- platform-bus@c000000 { +- interrupt-parent = <0x8002>; +- ranges = <0x00 0x00 0xc000000 0x2000000>; +- #address-cells = <0x01>; +- #size-cells = <0x01>; +- compatible = "qemu,platform", "simple-bus"; +- }; +- +``` diff --git a/results/classifier/gemma3:12b/device/2908 b/results/classifier/gemma3:12b/device/2908 new file mode 100644 index 000000000..9280bad05 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2908 @@ -0,0 +1,11 @@ + +Display Output Not Sane After Driver Installation +Description of problem: +Using an S3 Diamond Stealth 3000 card through VFIO, after installing an official driver, either from the Windows disc or an updated download, the displayed output from the graphics card is not sane. +Additional information: +Driver: [https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver](https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver) +[https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm](https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm) + +Followed the instructions in the Readme. To install Standard VGA driver first then the Diamond 3000 driver. No change. It is not the only S3 card that I have tried that behaves like this. I have also used the bios rom downloaded directly from the card, again with no change. + +# diff --git a/results/classifier/gemma3:12b/device/291 b/results/classifier/gemma3:12b/device/291 new file mode 100644 index 000000000..9abfd2040 --- /dev/null +++ b/results/classifier/gemma3:12b/device/291 @@ -0,0 +1,2 @@ + +deadlock in e1000e diff --git a/results/classifier/gemma3:12b/device/2916 b/results/classifier/gemma3:12b/device/2916 new file mode 100644 index 000000000..32ee3ffa4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2916 @@ -0,0 +1,27 @@ + +qemu-system-arm hangs when attempting to enable MMU on Cortex-A7 +Description of problem: +QEMU 9.x.x+ hangs when attempting to do enable the MMU from SCTLRL - M bit: https://developer.arm.com/documentation/ddi0601/2025-03/AArch32-Registers/SCTLR--System-Control-Register + +The instruction that hangs is the writing of the SCTLR register: + +``` +mrc p15, 0, r0, c1, c0, 0 +orr r0, r0, 1 +mcr p15, 0, r0, c1, c0, 0 +``` + +I am attempting to enable unaligned accesses and SCTLR-A bit doesn't seem to have any effect if the SCTLR-M is not enabled. Doing an unaligned access on cortex-a7 should be supported but it always trigger a Fault. +Steps to reproduce: +1. add the mrc/orr/mcr instruction sequence in the ResetHandler +2. link the elf +3. attempt to execute it +Additional information: +The unaligned access looked like it was working in QEMU 8.x.x but it might not have been emulated(?). I also am facing the same issues with MCR hanging and unaligned access not supported with latest 10.0.0-RC2. + +When it hangs, QEMU has to be killed and terminal reset. + +There might be two separate issues here: + +1. writing SCTLR register +2. emulated cortex-a7 not supporting unaligned access (hardware supports it) diff --git a/results/classifier/gemma3:12b/device/2917 b/results/classifier/gemma3:12b/device/2917 new file mode 100644 index 000000000..aeef88db7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2917 @@ -0,0 +1,23 @@ + +build failure because of warnings when -O3 is used +Description of problem: +qemu build fails when -O3 is enabled and the build is done either from a git cloned qemu or with -Werror enabled (qemu build enables -Werror automatically when it detects the .git folder) +Steps to reproduce: +1. git clone qemu && install appropriate dependencies for qemu build +2. mkdir build +3. ../configure --extra-cflags="-O3" +4. make -j$(nbproc) + +``` +cc -m64 -Ilibcommon.a.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Isubprojects/libvduse -I../subprojects/libvduse -I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0 -I/usr/include/SDL2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/slirp -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/webp -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/vte-2.91 -I/usr/include/virgl -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/PCSC -I/usr/include/pipewire-0.3 -I/usr/include/spa-0.2 -I/usr/include/fuse3 -I/usr/include/uuid -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem /home/ubuntu/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/ubuntu/qemu -iquote /home/ubuntu/qemu/include -iquote /home/ubuntu/qemu/host/include/x86_64 -iquote /home/ubuntu/qemu/host/include/generic -iquote /home/ubuntu/qemu/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -O3 -fPIE -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -D__USE_LARGEFILE64 -DUSE_POSIX_ACLS=1 -isystem /usr/include/mit-krb5 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.a.p/hw_ssi_xilinx_spips.c.o -MF libcommon.a.p/hw_ssi_xilinx_spips.c.o.d -o libcommon.a.p/hw_ssi_xilinx_spips.c.o -c ../hw/ssi/xilinx_spips.c +../hw/ssi/xilinx_spips.c: In function ‘xilinx_spips_flush_txfifo’: +../hw/ssi/xilinx_spips.c:624:30: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] + 624 | tx_rx[i] = fifo8_pop(&s->tx_fifo); + | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ +../hw/ssi/xilinx_spips.c:613:17: note: at offset 2 into destination object ‘tx_rx’ of size 2 + 613 | uint8_t tx_rx[MAX_NUM_BUSSES] = { 0 }; + | ^~~~~ +cc1: all warnings being treated as errors +``` +Additional information: +I fixed this warning locally on my build however it is only a start of several build warnings that happen down the road (\~6 warnings in total) diff --git a/results/classifier/gemma3:12b/device/2919 b/results/classifier/gemma3:12b/device/2919 new file mode 100644 index 000000000..4b90b1be4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/292 b/results/classifier/gemma3:12b/device/292 new file mode 100644 index 000000000..63a70921e --- /dev/null +++ b/results/classifier/gemma3:12b/device/292 @@ -0,0 +1,2 @@ + +keyboard errors in DOS, found links to similar errors for reference diff --git a/results/classifier/gemma3:12b/device/2920 b/results/classifier/gemma3:12b/device/2920 new file mode 100644 index 000000000..c3bcdc81c --- /dev/null +++ b/results/classifier/gemma3:12b/device/2920 @@ -0,0 +1,13 @@ + +VGA Passthrough I/O Lag on DOS (FreeDOS) System. +Description of problem: +VGA performance lags with passthrough when the OS is in graphics mode. It also seems to affect when key presses are registered with noticeable delay. +Steps to reproduce: +1. Install Doom (v1.9 Shareware.) +2. Run setup and disable sound. +3. Play game or watch demo. +Additional information: +I have tried multiple cards with no change in performance: + +**VGA compatible controller: S3 Graphics Ltd. 86c375 [ViRGE/DX] or 86c385 [ViRGE/GX] (rev 01) (prog-if 00 [VGA controller]) +VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R480 [Radeon X800 GTO] (prog-if 00 [VGA controller])** diff --git a/results/classifier/gemma3:12b/device/2929 b/results/classifier/gemma3:12b/device/2929 new file mode 100644 index 000000000..0cff29a01 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2929 @@ -0,0 +1,8 @@ + +Ask to extend vhost-user protocol to carry implementation defined error contexts +Additional information: +I am working on the Google [crosvm](https://chromium.googlesource.com/crosvm/crosvm/) project, which implements some `vhost-user` clients/servers defined by [this QEMU doc](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html). I am wondering if we could add a protocol feature/protocol header flag bit to allow the payload of the reply to carry detailed implementation defined error contexts? + +Specifically, I am working on the `vhost-user-gpu` device, which needs to send some memory mapping request to the frontend(the main process where VCPU lives), so that we can map some GPU memory to the guest. We are trying to diagnose a bug where the frontend can sometimes fail to perform the operation. However, we don't have access to the logs on the main process, so we are left with only very limited information on the `vhost-user-gpu` process. It could be helpful if we could send detailed implementation defined error contexts in the payload of the reply. + +I am wondering in order for the upstream QEMU to accept such "spec" change to the `vhost-user` protocol, what the process should be like? Thanks. diff --git a/results/classifier/gemma3:12b/device/2932 b/results/classifier/gemma3:12b/device/2932 new file mode 100644 index 000000000..7fd899b58 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2932 @@ -0,0 +1,2 @@ + +QEMU flag fuzz targets not WAI diff --git a/results/classifier/gemma3:12b/device/2939 b/results/classifier/gemma3:12b/device/2939 new file mode 100644 index 000000000..a386877c7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2939 @@ -0,0 +1,2 @@ + +Add m68k board name called Macintosh llci diff --git a/results/classifier/gemma3:12b/device/2941 b/results/classifier/gemma3:12b/device/2941 new file mode 100644 index 000000000..88339d23b --- /dev/null +++ b/results/classifier/gemma3:12b/device/2941 @@ -0,0 +1,2 @@ + +last chance add board called Macintosh llci diff --git a/results/classifier/gemma3:12b/device/2945 b/results/classifier/gemma3:12b/device/2945 new file mode 100644 index 000000000..bdb7378f2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2945 @@ -0,0 +1,30 @@ + +Commit da954d0e introduces a regression on sifive_unleashed when booting from SD card +Description of problem: +In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the sifive_unleashed target was failing to boot from SD card in our tests (we also test via SPI and this is fine). I have bisected the problem down to commit [da954d0e ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")](https://gitlab.com/qemu-project/qemu/-/commit/da954d0e32444f122a41c24948d4d1c718bf66d4). + +When running QEMU we see the following output in the failure case as the only output: +``` +U-Boot SPL 2025.07-rc1-00033-gad60d9792896 (May 01 2025 - 17:08:34 +0000) +Trying to boot from MMC1 +spl: mmc init failed with error: -110 +Error: -110 +SPL: failed to boot from all boot devices +# +Steps to reproduce: +1. wget -O - https://github.com/pengutronix/genimage/releases/download/v14/genimage-14.tar.xz | tar -C /tmp -xJ ; cd /tmp/genimage-14 +2. ./configure && make -j$(nproc) +3. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot +4. wget -O - https://github.com/riscv-software-src/opensbi/releases/download/v1.3.1/opensbi-1.3.1-rv-bin.tar.xz | tar -C /tmp -xJ +5. export OPENSBI=/tmp/opensbi-1.3.1-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin +6. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- sifive_unleashed_defconfig +7. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- -sj$(nproc) +8. mkdir -p root +9. cp /tmp/sifive_unleashed/spl/u-boot-spl.bin . +10. cp /tmp/sifive_unleashed/u-boot.itb . +11. rm -rf tmp +12. genimage --inputpath . --config board/sifive/unleashed/genimage_sdcard.cfg +13. cp images/sdcard.img /tmp/sifive_unleashed/ +14. qemu-system-riscv64 -smp 5 -m 8G -nographic -M sifive_u,msel=11 -bios /tmp/sifive_unleashed/spl/u-boot-spl.bin -drive file=/tmp/sifive_unleashed/sdcard.img,format=raw,if=sd +Additional information: +The genimage tool is required for making the disk images used here. If building everything here is too much, I can provide the U-Boot binaries needed here out of band. diff --git a/results/classifier/gemma3:12b/device/2948 b/results/classifier/gemma3:12b/device/2948 new file mode 100644 index 000000000..8e9244807 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2948 @@ -0,0 +1,14 @@ + +-display sdl causes mice with relative movement to read garbage offsets +Description of problem: +`-device virtio-mouse` and `-device usb-mouse` (and probably other mice which send relative mouse movement data) are behaving incorrectly under linux guest and jitter a lot. In this specific case it only seems to happen with `-display sdl` as I could not reproduce this same issue with other of the following configurations: `-display gtk` and `-display spice-app` running with virt-viewer. +This behavior is not present when running a Windows guest with the same configuration using `-display sdl` + +Another weird side note: this behavior is less apparent when running `evtest` on the exact mouse device having issues. + + +Steps to reproduce: +1. Install guest operating system +2. Install gnome metapackage and enable GDM +3. Reboot +4. The mouse shows jittery motion on the GDM screen. diff --git a/results/classifier/gemma3:12b/device/2950 b/results/classifier/gemma3:12b/device/2950 new file mode 100644 index 000000000..dc55592df --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2952 b/results/classifier/gemma3:12b/device/2952 new file mode 100644 index 000000000..9937f4be0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2952 @@ -0,0 +1,15 @@ + +Truncated bits while writing value to registers of RISC-V +Description of problem: +As mentioned above +Steps to reproduce: +``` +# 1. Compile the `test.S`: +riscv32-unknown-linux-gnu-gcc -g -static -nostartfiles -o test hello.S + +# 2. Execute the binary: +qemu-riscv32 ./test + +# 3. Check exit code +echo $? +``` diff --git a/results/classifier/gemma3:12b/device/2954 b/results/classifier/gemma3:12b/device/2954 new file mode 100644 index 000000000..3de2dbb88 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2954 @@ -0,0 +1,20 @@ + +SD card is not visible by UEFI +Description of problem: +SD card is not visible by OVMF UEFI, so it's not possible to boot from it: +``` +UEFI Interactive Shell v2.2 +EDK II +UEFI v2.70 (EDK II, 0x00010000) +Mapping table + BLK0: Alias(s): + PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0) +Press ESC in 1 seconds to skip startup.nsh or any other key to continue. +Shell> +``` +It is visible by SeaBIOS though, if we remove the OVMF part from the commandline: +``` +qemu-system-x86_64 -device sdhci-pci -drive if=none,file=Fedora-IoT-ostree-41-20241027.0.x86_64.iso,format=raw,id=MMC1 -device sd-card,drive=MMC1 +``` + +@philmd diff --git a/results/classifier/gemma3:12b/device/2956 b/results/classifier/gemma3:12b/device/2956 new file mode 100644 index 000000000..541b19574 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/2961 b/results/classifier/gemma3:12b/device/2961 new file mode 100644 index 000000000..2a7759782 --- /dev/null +++ b/results/classifier/gemma3:12b/device/2961 @@ -0,0 +1,32 @@ + +isapc: RTC refactor caused regression in qemu>=8.2 (broke Xenix, maybe others) +Description of problem: +I've been playing a bit with retro UNIXes and wanted to try a Xenix install. + +There are several webpages giving hints for installing Xenix under old versions of QEMU. The good news: most of the workarounds and tweaks they mention seem to be no longer needed. Starting with a Homebrew-supplied qemu 10.0.0 on my laptop I was able to do a basic install _without_ having to tweak the floppy geometry or anything like that. + +The bad news: once the install was complete and I tried to reboot from the harddrive it hangs at the... +``` +Boot +: +``` +...prompt. It doesn't respond to any keystrokes at this point. This prompt is printed by the second-stage loader (called `/boot` on the Xenix filesystem) which is a real-mode 8086 binary. + +To debug this further I moved to a more familiar Linux developer environment and found that the qemu that is stock with Debian 12.10 (7.2.15) did *not* exhibit the same problem! + +I manually bisected through the released versions and found that it definitely broke some time in the 8.2 release cycle: 8.1.5 worked, 8.2.0rc0 did not. I then did a git checkout and started building qemu, using `git bisect` to find the guilty commit. + +Soon I came across 56b1f50e3c101bfe5f52bac73de0e88438de11bd from @shentey -- a change which moved connecting the RTC's ISA interrupt from `pc_basic_device_init()` down into `*_realize()` when a Southbridge is configured. I was able to confirm that before this commit I could boot, but after it I could not. + +I verified using gdb that `pc_basic_device_init()` is being called but the functions that the initialization had moved to were not (or at least weren't called *yet*). So after this change this RTC irq wasn't being wired up, which apparently broke the second-stage Xenix loader. + +I then went back to git tip and found that reverting the 56b1f50e3c1 commit was enough to fix the problem there as well. + +I don't know enough about the qemu internals to judge whether the original change made sense. Therefore, I won't claim that reverting it is the correct approach to fix the bug. However, it did work for me. + +The Southbridge code has been reorged a little since 8.2 but the functional revert is still pretty straightfoward. Here is the diff I used: +[revert-56b1f50e3c1.patch](/uploads/573754b8af3d7ddb97d5f973cb0003db/revert-56b1f50e3c1.patch) +Steps to reproduce: +1. Install Xenix 2.3.4 from https://archive.org/details/sco-xenix-386-and-extras +2. After some enjoyable floppy juggling, be amazed at how smoothly the install went +3. Try to boot from the harddrive afterwards and weep diff --git a/results/classifier/gemma3:12b/device/2968 b/results/classifier/gemma3:12b/device/2968 new file mode 100644 index 000000000..8dbdc8dbd --- /dev/null +++ b/results/classifier/gemma3:12b/device/2968 @@ -0,0 +1,23 @@ + +Regression: x-igd-opregion=off ignored in VFIO IGD quirk handling +Description of problem: +A regression in QEMU’s VFIO IGD initialization causes the `x-igd-opregion=off` parameter to be ignored, resulting in an error when passing through an Intel iGPU SR-IOV Virtual Function (VF) at PCI address `00:02.1`: `qemu-system-x86_64: -device vfio-pci,host=0000:00:02.1,...: Device does not supports IGD OpRegion feature: No such device` +Automatic detection of IGD-OpRegion assumes any Intel iGPU (including GVT-g) will have it but SR-IOV VFs do not. +Steps to reproduce: +1. Configure an Intel iGPU with SR-IOV enabled, creating a VF at `00:02.1`. +2. Bind the VF to the `vfio-pci` driver: +``` + echo 0000:00:02.1 > /sys/bus/pci/drivers/i915/unbind + either: + echo "8086 4680" > /sys/bus/pci/drivers/vfio-pci/new_id + or: + echo 0000:00:02.1 > /sys/bus/pci/drivers/vfio-pci/bind +``` +3. Run QEMU with the command line above, including `-device vfio-pci,host=0000:00:02.1,...,x-igd-opregion=off`. +Additional information: +- **Hardware details**: + - `00:02.1 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)` + - Host motherboard: MSI PRO Z690-A DDR4 + - CPU: Intel Core i5 12600K +- **Regression cause**: The issue was introduced by commit 7be29f2f1a3f5b037d27eedbd5df9f441e8c8c16, which changed `vfio_pci_igd_config_quirk` to detect OpRegion automatically, ignoring `vdev->igd_opregion=false`. +- **Proposed fix**: I have a patch that adds checks for `vdev->igd_opregion` in `vfio_pci_igd_config_quirk` and `vfio_pci_kvmgt_config_quirk`, skipping OpRegion handling when `x-igd-opregion=off`. The patch has been tested, confirming the VM starts without errors. I will submit it to qemu-devel@nongnu.org with a reference to this issue. diff --git a/results/classifier/gemma3:12b/device/2976 b/results/classifier/gemma3:12b/device/2976 new file mode 100644 index 000000000..db292d20f --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/299 b/results/classifier/gemma3:12b/device/299 new file mode 100644 index 000000000..5210b34ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/299 @@ -0,0 +1,2 @@ + +Tulip NIC not working on OpenBSD/hppa (and more) diff --git a/results/classifier/gemma3:12b/device/300 b/results/classifier/gemma3:12b/device/300 new file mode 100644 index 000000000..68b1d6e5f --- /dev/null +++ b/results/classifier/gemma3:12b/device/300 @@ -0,0 +1,2 @@ + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again diff --git a/results/classifier/gemma3:12b/device/301 b/results/classifier/gemma3:12b/device/301 new file mode 100644 index 000000000..039093335 --- /dev/null +++ b/results/classifier/gemma3:12b/device/301 @@ -0,0 +1,2 @@ + +Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk diff --git a/results/classifier/gemma3:12b/device/302 b/results/classifier/gemma3:12b/device/302 new file mode 100644 index 000000000..eab667f0f --- /dev/null +++ b/results/classifier/gemma3:12b/device/302 @@ -0,0 +1,2 @@ + +[Fuzz] qemu-system-i386 virtio-mouse: Assertion in address_space_lduw_le_cached failed diff --git a/results/classifier/gemma3:12b/device/303 b/results/classifier/gemma3:12b/device/303 new file mode 100644 index 000000000..9efc5f527 --- /dev/null +++ b/results/classifier/gemma3:12b/device/303 @@ -0,0 +1,2 @@ + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed diff --git a/results/classifier/gemma3:12b/device/304 b/results/classifier/gemma3:12b/device/304 new file mode 100644 index 000000000..a33d5c4f3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/304 @@ -0,0 +1,2 @@ + +assertion failure in mptsas1068 emulator diff --git a/results/classifier/gemma3:12b/device/305 b/results/classifier/gemma3:12b/device/305 new file mode 100644 index 000000000..cb6c2fe63 --- /dev/null +++ b/results/classifier/gemma3:12b/device/305 @@ -0,0 +1,2 @@ + +assertion failure in lsi53c810 emulator diff --git a/results/classifier/gemma3:12b/device/322 b/results/classifier/gemma3:12b/device/322 new file mode 100644 index 000000000..713f35a1f --- /dev/null +++ b/results/classifier/gemma3:12b/device/322 @@ -0,0 +1,2 @@ + +Can't(?) disable default floppy drive any more in qemu 6.0 diff --git a/results/classifier/gemma3:12b/device/330 b/results/classifier/gemma3:12b/device/330 new file mode 100644 index 000000000..ee0f2cb26 --- /dev/null +++ b/results/classifier/gemma3:12b/device/330 @@ -0,0 +1,2 @@ + +TCG does not support x2APIC emulation diff --git a/results/classifier/gemma3:12b/device/332 b/results/classifier/gemma3:12b/device/332 new file mode 100644 index 000000000..2d4daa811 --- /dev/null +++ b/results/classifier/gemma3:12b/device/332 @@ -0,0 +1,2 @@ + +VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash diff --git a/results/classifier/gemma3:12b/device/338 b/results/classifier/gemma3:12b/device/338 new file mode 100644 index 000000000..96f240a98 --- /dev/null +++ b/results/classifier/gemma3:12b/device/338 @@ -0,0 +1,2 @@ + +QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c diff --git a/results/classifier/gemma3:12b/device/341 b/results/classifier/gemma3:12b/device/341 new file mode 100644 index 000000000..48906eb1b --- /dev/null +++ b/results/classifier/gemma3:12b/device/341 @@ -0,0 +1,2 @@ + +Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer diff --git a/results/classifier/gemma3:12b/device/342 b/results/classifier/gemma3:12b/device/342 new file mode 100644 index 000000000..d5a8ab8d6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/342 @@ -0,0 +1,2 @@ + +Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi diff --git a/results/classifier/gemma3:12b/device/345 b/results/classifier/gemma3:12b/device/345 new file mode 100644 index 000000000..fb872b710 --- /dev/null +++ b/results/classifier/gemma3:12b/device/345 @@ -0,0 +1,2 @@ + +Sector translation bug in scsi_unmap_complete_noio diff --git a/results/classifier/gemma3:12b/device/350 b/results/classifier/gemma3:12b/device/350 new file mode 100644 index 000000000..32cc923e2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/350 @@ -0,0 +1,2 @@ + +lsisas1068 not supported (for VMDK manipulation) diff --git a/results/classifier/gemma3:12b/device/360 b/results/classifier/gemma3:12b/device/360 new file mode 100644 index 000000000..eb4719bf9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/360 @@ -0,0 +1,2 @@ + +load_helper() do_unaligned_access path doesn't return correct result with MMIO diff --git a/results/classifier/gemma3:12b/device/370 b/results/classifier/gemma3:12b/device/370 new file mode 100644 index 000000000..90674c619 --- /dev/null +++ b/results/classifier/gemma3:12b/device/370 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the UI, graphics, audio and USB subsystem diff --git a/results/classifier/gemma3:12b/device/374 b/results/classifier/gemma3:12b/device/374 new file mode 100644 index 000000000..67e1c8d4c --- /dev/null +++ b/results/classifier/gemma3:12b/device/374 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the PPC subsystem diff --git a/results/classifier/gemma3:12b/device/379 b/results/classifier/gemma3:12b/device/379 new file mode 100644 index 000000000..c0511ef98 --- /dev/null +++ b/results/classifier/gemma3:12b/device/379 @@ -0,0 +1,2 @@ + +Update the FSF address to their current location diff --git a/results/classifier/gemma3:12b/device/383 b/results/classifier/gemma3:12b/device/383 new file mode 100644 index 000000000..5b2dd9e41 --- /dev/null +++ b/results/classifier/gemma3:12b/device/383 @@ -0,0 +1,2 @@ + +virtio-gpu: heap-buffer-overflow in virtio_gpu_disable_scanout diff --git a/results/classifier/gemma3:12b/device/386 b/results/classifier/gemma3:12b/device/386 new file mode 100644 index 000000000..902afece8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/386 @@ -0,0 +1,2 @@ + +raspi0 machine has incorrect memory mapping for devices diff --git a/results/classifier/gemma3:12b/device/387 b/results/classifier/gemma3:12b/device/387 new file mode 100644 index 000000000..d0e056a18 --- /dev/null +++ b/results/classifier/gemma3:12b/device/387 @@ -0,0 +1,2 @@ + +SD-Card not working anymore on x86 targets diff --git a/results/classifier/gemma3:12b/device/388 b/results/classifier/gemma3:12b/device/388 new file mode 100644 index 000000000..b983d3dfa --- /dev/null +++ b/results/classifier/gemma3:12b/device/388 @@ -0,0 +1,2 @@ + +Can not pass hw device names as alsa input and output devices diff --git a/results/classifier/gemma3:12b/device/391 b/results/classifier/gemma3:12b/device/391 new file mode 100644 index 000000000..32fc4fc86 --- /dev/null +++ b/results/classifier/gemma3:12b/device/391 @@ -0,0 +1,2 @@ + +Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest diff --git a/results/classifier/gemma3:12b/device/392 b/results/classifier/gemma3:12b/device/392 new file mode 100644 index 000000000..27797eaa5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/392 @@ -0,0 +1,2 @@ + +`-hda` and `-drive` differ with respect to path handling diff --git a/results/classifier/gemma3:12b/device/401 b/results/classifier/gemma3:12b/device/401 new file mode 100644 index 000000000..47c6366c5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/401 @@ -0,0 +1,2 @@ + +Wishlist: nvme-ns: allow specifying eui-64 diff --git a/results/classifier/gemma3:12b/device/405 b/results/classifier/gemma3:12b/device/405 new file mode 100644 index 000000000..b04d555c3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/405 @@ -0,0 +1,2 @@ + +Assertion failure in e1000e_intrmgr_on_throttling_timer diff --git a/results/classifier/gemma3:12b/device/410 b/results/classifier/gemma3:12b/device/410 new file mode 100644 index 000000000..9e0f008f7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/410 @@ -0,0 +1,2 @@ + +Abort in audio_bug triggered in sb16/pl041 diff --git a/results/classifier/gemma3:12b/device/411 b/results/classifier/gemma3:12b/device/411 new file mode 100644 index 000000000..ec2411e42 --- /dev/null +++ b/results/classifier/gemma3:12b/device/411 @@ -0,0 +1,2 @@ + +Abort when runs into unsupported AUXCommand in xlnx_dp_aux_set_command diff --git a/results/classifier/gemma3:12b/device/413 b/results/classifier/gemma3:12b/device/413 new file mode 100644 index 000000000..1e60a7b7b --- /dev/null +++ b/results/classifier/gemma3:12b/device/413 @@ -0,0 +1,2 @@ + +Error handling: Audit callers of load_image_targphys, get_image_size, event_notifier_init, msix_init diff --git a/results/classifier/gemma3:12b/device/423 b/results/classifier/gemma3:12b/device/423 new file mode 100644 index 000000000..6954b6af5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/423 @@ -0,0 +1,2 @@ + +NVME disk cannot be hotplugged after removal diff --git a/results/classifier/gemma3:12b/device/424 b/results/classifier/gemma3:12b/device/424 new file mode 100644 index 000000000..2be622826 --- /dev/null +++ b/results/classifier/gemma3:12b/device/424 @@ -0,0 +1,2 @@ + +the option for vdagent communication needed for qxl scren resizing is not documented diff --git a/results/classifier/gemma3:12b/device/424450 b/results/classifier/gemma3:12b/device/424450 new file mode 100644 index 000000000..4b650fe92 --- /dev/null +++ b/results/classifier/gemma3:12b/device/424450 @@ -0,0 +1,15 @@ + +FDC reset should reset the MSR + +I believe that the MSR resgister should also be reset to zero on a software reset. All of the FDC hardware I have does this. +The current code leaves the MSR as 0x80, which means that the controller is ready for a write. The controller should not +be ready for a write while in reset. + +fdc.c Line 899 + /* Reset */ + if (!(value & FD_DOR_nRESET)) { + + fdctrl->msr = 0x00; + if (fdctrl->dor & FD_DOR_nRESET) { + FLOPPY_DPRINTF("controller enter RESET state\n"); + } + } else { \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/431 b/results/classifier/gemma3:12b/device/431 new file mode 100644 index 000000000..3b0230e2e --- /dev/null +++ b/results/classifier/gemma3:12b/device/431 @@ -0,0 +1,2 @@ + +USB passthrough in Windows Host non functional diff --git a/results/classifier/gemma3:12b/device/433 b/results/classifier/gemma3:12b/device/433 new file mode 100644 index 000000000..508f60099 --- /dev/null +++ b/results/classifier/gemma3:12b/device/433 @@ -0,0 +1,2 @@ + +chardev: Windows stdio eats characters diff --git a/results/classifier/gemma3:12b/device/437 b/results/classifier/gemma3:12b/device/437 new file mode 100644 index 000000000..9ca6e7902 --- /dev/null +++ b/results/classifier/gemma3:12b/device/437 @@ -0,0 +1,2 @@ + +[AHCI] crash when running a GNU/Hurd guest diff --git a/results/classifier/gemma3:12b/device/438 b/results/classifier/gemma3:12b/device/438 new file mode 100644 index 000000000..42c55dafa --- /dev/null +++ b/results/classifier/gemma3:12b/device/438 @@ -0,0 +1,2 @@ + +[alpha] FEN bit not honored in system mode diff --git a/results/classifier/gemma3:12b/device/44 b/results/classifier/gemma3:12b/device/44 new file mode 100644 index 000000000..18c39c3ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/44 @@ -0,0 +1,2 @@ + +QEMU aborts when specifying additional isa-vga devices diff --git a/results/classifier/gemma3:12b/device/441672 b/results/classifier/gemma3:12b/device/441672 new file mode 100644 index 000000000..e45174393 --- /dev/null +++ b/results/classifier/gemma3:12b/device/441672 @@ -0,0 +1,13 @@ + +Windos XP BSOD with HP Photosmart usb device attached + +https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details of the problem. + +I was just testing attaching a USB device to see if it really worked, and tried my HP Photosmart C5580 All-in-One +printer/scanner, and the Windows XP box then started getting bluescreens and crashing at random +(fairly short :-) intervals. + +My latest attempt was on a fedora rawhide system with pretty up to date software +(qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen. + +A reply to that bugzilla recommended adding this upstream bug, so here it is. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/446 b/results/classifier/gemma3:12b/device/446 new file mode 100644 index 000000000..9f06f0e9f --- /dev/null +++ b/results/classifier/gemma3:12b/device/446 @@ -0,0 +1,2 @@ + +usb-audio does not work with Mac OS diff --git a/results/classifier/gemma3:12b/device/450 b/results/classifier/gemma3:12b/device/450 new file mode 100644 index 000000000..a2467243b --- /dev/null +++ b/results/classifier/gemma3:12b/device/450 @@ -0,0 +1,2 @@ + +sdhci: Assertion wpnum < sd->wpgrps_size failed diff --git a/results/classifier/gemma3:12b/device/451 b/results/classifier/gemma3:12b/device/451 new file mode 100644 index 000000000..7f2f5ec1d --- /dev/null +++ b/results/classifier/gemma3:12b/device/451 @@ -0,0 +1,2 @@ + +sdhci: Heap-buffer-overflow in sdhci_read_dataport diff --git a/results/classifier/gemma3:12b/device/464 b/results/classifier/gemma3:12b/device/464 new file mode 100644 index 000000000..683788ede --- /dev/null +++ b/results/classifier/gemma3:12b/device/464 @@ -0,0 +1,2 @@ + +The virtio disk shows offline when try to install windows version v6.0.5 diff --git a/results/classifier/gemma3:12b/device/468 b/results/classifier/gemma3:12b/device/468 new file mode 100644 index 000000000..9be41b422 --- /dev/null +++ b/results/classifier/gemma3:12b/device/468 @@ -0,0 +1,2 @@ + +Zynq7000 UART clock reset initialization diff --git a/results/classifier/gemma3:12b/device/469 b/results/classifier/gemma3:12b/device/469 new file mode 100644 index 000000000..235d1ebca --- /dev/null +++ b/results/classifier/gemma3:12b/device/469 @@ -0,0 +1,2 @@ + +SB16 audio playback freezes emulation in Windows 95 guest diff --git a/results/classifier/gemma3:12b/device/472 b/results/classifier/gemma3:12b/device/472 new file mode 100644 index 000000000..e23af16ff --- /dev/null +++ b/results/classifier/gemma3:12b/device/472 @@ -0,0 +1,2 @@ + +Device trees should specify `clock-frequency` property for `/cpus/cpu*` nodes diff --git a/results/classifier/gemma3:12b/device/484 b/results/classifier/gemma3:12b/device/484 new file mode 100644 index 000000000..dd59c4960 --- /dev/null +++ b/results/classifier/gemma3:12b/device/484 @@ -0,0 +1,2 @@ + +6.1 Regression: machine pflash parsing diff --git a/results/classifier/gemma3:12b/device/485 b/results/classifier/gemma3:12b/device/485 new file mode 100644 index 000000000..d55466553 --- /dev/null +++ b/results/classifier/gemma3:12b/device/485 @@ -0,0 +1,2 @@ + +Failed to restore domain - error load load virtio-balloon:virtio diff --git a/results/classifier/gemma3:12b/device/487 b/results/classifier/gemma3:12b/device/487 new file mode 100644 index 000000000..af52b25f7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/487 @@ -0,0 +1,2 @@ + +sdhci: out of bounds read on sd->sd_status diff --git a/results/classifier/gemma3:12b/device/495 b/results/classifier/gemma3:12b/device/495 new file mode 100644 index 000000000..b666ab15f --- /dev/null +++ b/results/classifier/gemma3:12b/device/495 @@ -0,0 +1,2 @@ + +sdhci: Another way to trigger Assertion wpnum < sd->wpgrps_size failed diff --git a/results/classifier/gemma3:12b/device/500 b/results/classifier/gemma3:12b/device/500 new file mode 100644 index 000000000..2923de274 --- /dev/null +++ b/results/classifier/gemma3:12b/device/500 @@ -0,0 +1,2 @@ + +6.1.0-rc0 Regression: Parameter 'audiodev' is missing diff --git a/results/classifier/gemma3:12b/device/501 b/results/classifier/gemma3:12b/device/501 new file mode 100644 index 000000000..4b143ceea --- /dev/null +++ b/results/classifier/gemma3:12b/device/501 @@ -0,0 +1,2 @@ + +6.1.0-rc0 Regression: No keyboard input possible diff --git a/results/classifier/gemma3:12b/device/506 b/results/classifier/gemma3:12b/device/506 new file mode 100644 index 000000000..5f8fe97a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/506 @@ -0,0 +1,2 @@ + +ga: auto-discover virtio port using sysfs diff --git a/results/classifier/gemma3:12b/device/512 b/results/classifier/gemma3:12b/device/512 new file mode 100644 index 000000000..2597364ff --- /dev/null +++ b/results/classifier/gemma3:12b/device/512 @@ -0,0 +1,2 @@ + +6.1.0-rc1 New regression (not in 6.1.0-rc0): Freezes using UEFI firmware without acceleration diff --git a/results/classifier/gemma3:12b/device/516 b/results/classifier/gemma3:12b/device/516 new file mode 100644 index 000000000..4c707b5af --- /dev/null +++ b/results/classifier/gemma3:12b/device/516 @@ -0,0 +1,43 @@ + +Configure option `--enable-plugins` makes modules in shared library not loadable on macOS +Description of problem: +The title mentions `--enable-plugins` option, however as it's enabled by default, not providing `--disable-plugins` would also cause this to happen. + +If TCG plugin support is enabled, symbols in `qemu-system-*` binaries will be missing, and module libraries would fail to load as they expect those symbols to exist in the main binary. + +Configure options used: `STRIP="strip -x" ./configure --enable-user --enable-tools --enable-parallels --enable-libxml2 --enable-spice --enable-hvf --enable-cocoa --enable-guest-agent --enable-curses --enable-plugins --enable-modules --objcc=gcc --enable-libusb --enable-usb-redir` + +After inspecting the compiler command line, I've found the linker option `-Wl,-exported_symbols_list,qemu-plugins-ld64.symbols` is causing this to happen: only symbols listed in `qemu-plugins-ld64.symbols` would be kept in `qemu-system-*` binaries and all other symbols will be hidden. + +Note that this is not caused by stripping (although I had to use custom strip command line on macOS to successfully compile qemu); the option `-exported_symbols_list` works by only exposing the provided symbols and treating all other symbols as `visibility=hidden`. + +Replacing `--enable-plugins` to `--disable-plugins` in the above configure command line would "fix" it, although it means TCG plugins will not be supported. +Steps to reproduce: +1. Build QEMU on macOS with plugin support enabled +2. Try to use modules in shared library like qxl +Additional information: +Some examples: + +``` +$ qemu-system-x86_64 -device qxl +Failed to open module: dlopen(/usr/local/bin/../lib/qemu/ui-spice-core.dylib, 10): Symbol not found: __TRACE_QEMU_SPICE_ADD_MEMSLOT_DSTATE + Referenced from: /usr/local/bin/../lib/qemu/ui-spice-core.dylib + Expected in: flat namespace + in /usr/local/bin/../lib/qemu/ui-spice-core.dylib +Failed to open module: dlopen(/usr/local/bin/../lib/qemu/hw-display-qxl.dylib, 2): Symbol not found: __TRACE_QXL_CLIENT_MONITORS_CONFIG_CAPPED_DSTATE + Referenced from: /usr/local/bin/../lib/qemu/hw-display-qxl.dylib + Expected in: flat namespace + in /usr/local/bin/../lib/qemu/hw-display-qxl.dylib +qemu-system-x86_64: -device qxl: 'qxl' is not a valid device model name +``` + +``` +$ qemu-system-x86_64 -spice port=5901 +Failed to open module: dlopen(/usr/local/bin/../lib/qemu/ui-spice-core.dylib, 10): Symbol not found: __TRACE_QEMU_SPICE_ADD_MEMSLOT_DSTATE + Referenced from: /usr/local/bin/../lib/qemu/ui-spice-core.dylib + Expected in: flat namespace + in /usr/local/bin/../lib/qemu/ui-spice-core.dylib +qemu-system-x86_64: -spice port=5901: spice support is disabled +``` + +After disabling plugin support I could run virtual machines locally through libvirt with full spice and qxl video support. diff --git a/results/classifier/gemma3:12b/device/519 b/results/classifier/gemma3:12b/device/519 new file mode 100644 index 000000000..a36febedd --- /dev/null +++ b/results/classifier/gemma3:12b/device/519 @@ -0,0 +1,34 @@ + +xive: An extra '0x' prefix when printing hex values in the trace. +Description of problem: +The trace functions corresponding to the functions below print certain +parameters with a double "0x" prefix, i.e., with "0x0x". + + +- xive_source_esb_read +- xive_source_esb_write +- xive_tctx_tm_write +- xive_tctx_tm_read +Steps to reproduce: +1. Execute the command line on a terminal +2. Watch the terminal for the output. +Additional information: +Sample output: + + xive_end_source_read END 0x0/0xf @0x0x1e0800 + xive_source_esb_read @0x0x210c00 IRQ 0x10 val=0x0x1 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x0 + xive_tctx_tm_write @0x0x10038 sz=1 val=0x80 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x80 + xive_end_source_read END 0x0/0xf @0x0x1e0800 + xive_source_esb_read @0x0x210c00 IRQ 0x10 val=0x0x1 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x0 + xive_tctx_tm_write @0x0x10038 sz=1 val=0x80 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x80 + +The source lines at fault: + + xive_source_esb_read(uint64_t addr, uint32_t srcno, uint64_t value) "@0x0x%"PRIx64" IRQ 0x%x val=0x0x%"PRIx64 + xive_source_esb_write(uint64_t addr, uint32_t srcno, uint64_t value) "@0x0x%"PRIx64" IRQ 0x%x val=0x0x%"PRIx64 + xive_tctx_tm_write(uint64_t offset, unsigned int size, uint64_t value) "@0x0x%"PRIx64" sz=%d val=0x%" PRIx64 + xive_tctx_tm_read(uint64_t offset, unsigned int size, uint64_t value) "@0x0x%"PRIx64" sz=%d val=0x%" PRIx64 diff --git a/results/classifier/gemma3:12b/device/521 b/results/classifier/gemma3:12b/device/521 new file mode 100644 index 000000000..965c7379b --- /dev/null +++ b/results/classifier/gemma3:12b/device/521 @@ -0,0 +1,2 @@ + +Assert mr != NULL through megaraid diff --git a/results/classifier/gemma3:12b/device/522 b/results/classifier/gemma3:12b/device/522 new file mode 100644 index 000000000..8ea273813 --- /dev/null +++ b/results/classifier/gemma3:12b/device/522 @@ -0,0 +1,55 @@ + +qemu gets SIGSEGV when starting with vhost-user-blk-pci device +Description of problem: +as subject +Steps to reproduce: +1. Prepare an qemu-storage-daemon process for vhost-user +``` +qemu-img create /tmp/test 100M +``` +``` +/usr/bin/qemu-storage-daemon --blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/test.img","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' --blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}' --export vhost-user-blk,id=vhost-user-blk0,node-name=libvirt-1-format,addr.type=unix,addr.path=/tmp/vhost.sock,writable=on --chardev stdio,mux=on,id=char0 +``` +2. Run the qemu cmdline above. Then SIGSEGV. +And the error of qemu-storage-daemon:`qemu-storage-daemon: vu_panic: Invalid queue index: 1` +Additional information: +Backtrace: +``` +#0 0x0000557105198937 in vhost_user_read_cb (source=0x55710677be90, condition=<optimized out>, opaque=0x7ffe8b208ee0) at ../hw/virtio/vhost-user.c:313 +#1 0x00007f7e7ec422af in g_main_dispatch (context=0x557107b02070) at ../glib/gmain.c:3344 +#2 g_main_context_dispatch (context=0x557107b02070) at ../glib/gmain.c:4062 +#3 0x00007f7e7ec96df8 in g_main_context_iterate.constprop.0 (context=0x557107b02070, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4138 +#4 0x00007f7e7ec41873 in g_main_loop_run (loop=0x557107b02570) at ../glib/gmain.c:4336 +#5 0x000055710519770a in vhost_user_read (dev=dev@entry=0x7f7df46443f8, msg=msg@entry=0x7ffe8b208f50) at ../hw/virtio/vhost-user.c:402 +#6 0x000055710519808f in vhost_user_get_config (dev=0x7f7df46443f8, config=0x7f7df46443ac "", config_len=60) at ../hw/virtio/vhost-user.c:2133 +#7 0x0000557105152af1 in vhost_user_blk_device_realize (dev=0x7f7df46441b0, errp=<optimized out>) at ../hw/block/vhost-user-blk.c:503 +#8 0x000055710518cb9c in virtio_device_realize (dev=0x7f7df46441b0, errp=0x7ffe8b2092e0) at ../hw/virtio/virtio.c:3660 +#9 0x00005571051d7abd in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7ffe8b209360) at ../hw/core/qdev.c:761 +#10 0x00005571051da62a in property_set_bool (obj=0x7f7df46441b0, v=<optimized out>, name=<optimized out>, opaque=0x55710653c150, errp=0x7ffe8b209360) at ../qom/object.c:2257 +#11 0x00005571051dd3ac in object_property_set (obj=obj@entry=0x7f7df46441b0, name=name@entry=0x55710541bab9 "realized", v=v@entry=0x557107afbc80, errp=errp@entry=0x7ffe8b209470) + at ../qom/object.c:1402 +#12 0x00005571051e08f4 in object_property_set_qobject + (obj=obj@entry=0x7f7df46441b0, name=name@entry=0x55710541bab9 "realized", value=value@entry=0x557107afbbc0, errp=errp@entry=0x7ffe8b209470) at ../qom/qom-qobject.c:28 +#13 0x00005571051dd9c9 in object_property_set_bool (obj=0x7f7df46441b0, name=0x55710541bab9 "realized", value=<optimized out>, errp=0x7ffe8b209470) at ../qom/object.c:1472 +#14 0x0000557104fe813c in pci_qdev_realize (qdev=<optimized out>, errp=<optimized out>) at ../hw/pci/pci.c:2117 +#15 0x00005571051d7abd in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7ffe8b209590) at ../hw/core/qdev.c:761 +#16 0x00005571051da62a in property_set_bool (obj=0x7f7df463c010, v=<optimized out>, name=<optimized out>, opaque=0x55710653c150, errp=0x7ffe8b209590) at ../qom/object.c:2257 +#17 0x00005571051dd3ac in object_property_set (obj=obj@entry=0x7f7df463c010, name=name@entry=0x55710541bab9 "realized", v=v@entry= + 0x557107af5e80, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../qom/object.c:1402 +#18 0x00005571051e08f4 in object_property_set_qobject + (obj=obj@entry=0x7f7df463c010, name=name@entry=0x55710541bab9 "realized", value=value@entry=0x557107af5e40, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../qom/qom-qobject.c:28 +#19 0x00005571051dd9c9 in object_property_set_bool (obj=0x7f7df463c010, name=name@entry=0x55710541bab9 "realized", value=value@entry=true, errp=errp@entry=0x5571057e2db0 <error_fatal>) + at ../qom/object.c:1472 +#20 0x00005571051d8052 in qdev_realize (dev=<optimized out>, bus=bus@entry=0x5571073ffeb0, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../hw/core/qdev.c:389 +#21 0x0000557104ec5e28 in qdev_device_add (opts=0x557106534000, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../softmmu/qdev-monitor.c:674 +#22 0x00005571050f4bf3 in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x5571057e2db0 <error_fatal>) at ../softmmu/vl.c:1212 +#23 0x0000557105302282 in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x5571050f4be0 <device_init_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x5571057e2db0 <error_fatal>) + at ../util/qemu-option.c:1168 +#24 0x00005571050f7532 in qemu_create_cli_devices () at ../softmmu/vl.c:2587 +#25 qmp_x_exit_preconfig (errp=<optimized out>) at ../softmmu/vl.c:2635 +#26 0x00005571050fb5ac in qmp_x_exit_preconfig (errp=<optimized out>) at ../softmmu/vl.c:2629 +#27 qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:3669 +#28 0x0000557104e87b1d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49 +``` + +Get full threads backtrace on the attachment [gdb.zip](/uploads/3cbc168cad60a1472e9e3f323207de9d/gdb.zip) diff --git a/results/classifier/gemma3:12b/device/531 b/results/classifier/gemma3:12b/device/531 new file mode 100644 index 000000000..78b866323 --- /dev/null +++ b/results/classifier/gemma3:12b/device/531 @@ -0,0 +1,2 @@ + +Replace DMA processing in I/O handlers by asynchronous BH diff --git a/results/classifier/gemma3:12b/device/532 b/results/classifier/gemma3:12b/device/532 new file mode 100644 index 000000000..2e802dedf --- /dev/null +++ b/results/classifier/gemma3:12b/device/532 @@ -0,0 +1,2 @@ + +USB-EHCI: Replace DMA processing in I/O handlers by asynchronous BH diff --git a/results/classifier/gemma3:12b/device/536 b/results/classifier/gemma3:12b/device/536 new file mode 100644 index 000000000..fe8c81e6a --- /dev/null +++ b/results/classifier/gemma3:12b/device/536 @@ -0,0 +1,2 @@ + +Null-ptr dereference in ich9_apm_ctrl_changed diff --git a/results/classifier/gemma3:12b/device/540 b/results/classifier/gemma3:12b/device/540 new file mode 100644 index 000000000..0c642bde3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/540 @@ -0,0 +1,2 @@ + +Heap-use-after-free in usb_packet_unmap through xhci diff --git a/results/classifier/gemma3:12b/device/541 b/results/classifier/gemma3:12b/device/541 new file mode 100644 index 000000000..13f200783 --- /dev/null +++ b/results/classifier/gemma3:12b/device/541 @@ -0,0 +1,2 @@ + +Heap-use-after-free through ehci_flush_qh diff --git a/results/classifier/gemma3:12b/device/542 b/results/classifier/gemma3:12b/device/542 new file mode 100644 index 000000000..f121e57f6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/542 @@ -0,0 +1,2 @@ + +Stack-overflow in ldl_le_dma through intel-hda (CVE-2021-3611) diff --git a/results/classifier/gemma3:12b/device/543 b/results/classifier/gemma3:12b/device/543 new file mode 100644 index 000000000..fc16546bf --- /dev/null +++ b/results/classifier/gemma3:12b/device/543 @@ -0,0 +1,2 @@ + +virtio-blk: ASSERT: !s->dataplane_started diff --git a/results/classifier/gemma3:12b/device/544 b/results/classifier/gemma3:12b/device/544 new file mode 100644 index 000000000..3e5c59740 --- /dev/null +++ b/results/classifier/gemma3:12b/device/544 @@ -0,0 +1,2 @@ + +Assert xfer->packet.status != USB_RET_NAK in xhci diff --git a/results/classifier/gemma3:12b/device/545 b/results/classifier/gemma3:12b/device/545 new file mode 100644 index 000000000..43d69f840 --- /dev/null +++ b/results/classifier/gemma3:12b/device/545 @@ -0,0 +1,2 @@ + +Abort in ohci_frame_boundary diff --git a/results/classifier/gemma3:12b/device/546 b/results/classifier/gemma3:12b/device/546 new file mode 100644 index 000000000..9dcd64bd7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/546 @@ -0,0 +1,2 @@ + +Global-buffer-overflow in mode_sense_page diff --git a/results/classifier/gemma3:12b/device/548 b/results/classifier/gemma3:12b/device/548 new file mode 100644 index 000000000..cacc63bc6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/548 @@ -0,0 +1,2 @@ + +Null-ptr dereference in megasas_finish_dcmd diff --git a/results/classifier/gemma3:12b/device/55 b/results/classifier/gemma3:12b/device/55 new file mode 100644 index 000000000..4da947109 --- /dev/null +++ b/results/classifier/gemma3:12b/device/55 @@ -0,0 +1,2 @@ + +Can't install Windows 7 with q35 (SATA) diff --git a/results/classifier/gemma3:12b/device/550 b/results/classifier/gemma3:12b/device/550 new file mode 100644 index 000000000..022ec6380 --- /dev/null +++ b/results/classifier/gemma3:12b/device/550 @@ -0,0 +1,2 @@ + +FPE in npcm7xx_adc_convert diff --git a/results/classifier/gemma3:12b/device/552 b/results/classifier/gemma3:12b/device/552 new file mode 100644 index 000000000..6759da169 --- /dev/null +++ b/results/classifier/gemma3:12b/device/552 @@ -0,0 +1,2 @@ + +assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed diff --git a/results/classifier/gemma3:12b/device/553 b/results/classifier/gemma3:12b/device/553 new file mode 100644 index 000000000..87e1ff676 --- /dev/null +++ b/results/classifier/gemma3:12b/device/553 @@ -0,0 +1,26 @@ + +Virtio-vga with blobs on fails, when qemu compiled with enabled modules +Description of problem: +When using qemu configured with `--enabled-modules` and starting qemu with command line above, qemu crashes with following output: +``` +qemu-system-x86_64: -device virtio-vga,blob=on: cannot enable blob resources without udmabuf +``` +While qemu configured without `--enabled-modules` runs this command successfully. +Steps to reproduce: +1. Get latest qemu source code +2. Build qemu `mkdir build && cd build && ../configure && ninja` +3. Check if following command runs without errors and show sdl qemu window + ``` + sudo ./qemu-system-x86_64 \ + -object memory-backend-memfd,id=mem1,size=512M \ + -machine memory-backend=mem1 \ + -display sdl \ + -device virtio-vga,blob=on + + ``` +4. Then try to build with modules enabled `mkdir build && cd build && ../configure --enable-modules && ninja` +5. Try to do step 3 again +Additional information: +I tried to debug this bug, and found that problem is with function `virtio_gpu_have_udmabuf`: when qemu is build without modules this function is from `hw/display/virtio-gpu-udmabuf.c` (which is correct), but when qemu compiled with modules this function comes from `stubs/virtio-gpu-udmabuf.c` and when `hw-display-virtio-gpu.so` is loaded, `virtio_gpu_have_udmabuf` is not replaced, and remains function from stub (which always return 0) and command fails. + +I think I will submit patch that fix it tomorrow diff --git a/results/classifier/gemma3:12b/device/554 b/results/classifier/gemma3:12b/device/554 new file mode 100644 index 000000000..921944102 --- /dev/null +++ b/results/classifier/gemma3:12b/device/554 @@ -0,0 +1,2 @@ + +q35 machine type cdrom device not discovered by freedos diff --git a/results/classifier/gemma3:12b/device/556 b/results/classifier/gemma3:12b/device/556 new file mode 100644 index 000000000..295f2a760 --- /dev/null +++ b/results/classifier/gemma3:12b/device/556 @@ -0,0 +1,20 @@ + +Fix DMA MMIO reentrancy issues +Additional information: +List of `DMA reentrancy` issues (usually found by [fuzzer](https://gitlab.com/qemu-project/qemu/-/issues?label_name[]=Fuzzer)): +- #62 (AHCI) +- #84, #305, #552 (SCSI) +- #451, #1282 (SDHCI) +- #540 (xHCI) +- #541 (EHCI) +- #542 (HDA) +- #557 (pcnet) +- #782 (NVMe) +- [eepro100](https://lore.kernel.org/qemu-devel/20210218140629.373646-1-ppandit@redhat.com/) +- #827 (virtio-blk) +- #1171 (tulip) +- #1543 (e1000e) +- #1563 (lsi53c895a) + + +Usually coredump backtrace includes multiple calls to `access_with_adjusted_size()` from the Memory API. diff --git a/results/classifier/gemma3:12b/device/56 b/results/classifier/gemma3:12b/device/56 new file mode 100644 index 000000000..04711447c --- /dev/null +++ b/results/classifier/gemma3:12b/device/56 @@ -0,0 +1,2 @@ + +Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused] diff --git a/results/classifier/gemma3:12b/device/561 b/results/classifier/gemma3:12b/device/561 new file mode 100644 index 000000000..9a1d32fe7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/561 @@ -0,0 +1,2 @@ + +Q35 - ACPI PCI hot-plug issue with Windows guest diff --git a/results/classifier/gemma3:12b/device/565 b/results/classifier/gemma3:12b/device/565 new file mode 100644 index 000000000..dda389325 --- /dev/null +++ b/results/classifier/gemma3:12b/device/565 @@ -0,0 +1,2 @@ + +maybe-uninitialized warning in Xtensa flush_window_regs() diff --git a/results/classifier/gemma3:12b/device/568 b/results/classifier/gemma3:12b/device/568 new file mode 100644 index 000000000..4445aea20 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/569 b/results/classifier/gemma3:12b/device/569 new file mode 100644 index 000000000..4c85e0416 --- /dev/null +++ b/results/classifier/gemma3:12b/device/569 @@ -0,0 +1,2 @@ + +ESP SCSI adapter not working with DOS ASPI drivers diff --git a/results/classifier/gemma3:12b/device/570 b/results/classifier/gemma3:12b/device/570 new file mode 100644 index 000000000..59b809d6b --- /dev/null +++ b/results/classifier/gemma3:12b/device/570 @@ -0,0 +1,2 @@ + +linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined diff --git a/results/classifier/gemma3:12b/device/572 b/results/classifier/gemma3:12b/device/572 new file mode 100644 index 000000000..3f6ef6ea6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/572 @@ -0,0 +1,2 @@ + +s390-pci-bus.h:85: warning: "PAGE_SIZE" redefined diff --git a/results/classifier/gemma3:12b/device/573 b/results/classifier/gemma3:12b/device/573 new file mode 100644 index 000000000..e681d706f --- /dev/null +++ b/results/classifier/gemma3:12b/device/573 @@ -0,0 +1,2 @@ + +maybe-uninitialized warning in pnv_phb3_translate_iommu() diff --git a/results/classifier/gemma3:12b/device/576 b/results/classifier/gemma3:12b/device/576 new file mode 100644 index 000000000..1b6738ea3 --- /dev/null +++ b/results/classifier/gemma3:12b/device/576 @@ -0,0 +1,2 @@ + +New Cocoa clipboard support raises minimum macos version to 10.14 diff --git a/results/classifier/gemma3:12b/device/581 b/results/classifier/gemma3:12b/device/581 new file mode 100644 index 000000000..2c4b342b9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/586 b/results/classifier/gemma3:12b/device/586 new file mode 100644 index 000000000..1862bb7b9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/586 @@ -0,0 +1,2 @@ + +virtio-gpu: qemu 6.1.0 no longer enables virgl when using '-vga virtio' diff --git a/results/classifier/gemma3:12b/device/587 b/results/classifier/gemma3:12b/device/587 new file mode 100644 index 000000000..349caaac8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/587 @@ -0,0 +1,2 @@ + +qemu show no error but the virtual machine stuck in boot (GPU passthrough) diff --git a/results/classifier/gemma3:12b/device/588688 b/results/classifier/gemma3:12b/device/588688 new file mode 100644 index 000000000..579f8e3e4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/588688 @@ -0,0 +1,8 @@ + +Hard disk images are supporting ATAPI commands. They should fail. + +When using a hard disk image (qcow, qcow2, vdi, vmdk, bochs), the emulated device can be a CD-ROM and support ATAPI commands. + +These commands fails in real hard disks and these images are not prepared to handle optical disk formats, they should fail also. + +Only images able to handle that formats (dmg, raw, host) should work with ATAPI commands and CD-ROM devices. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/588691 b/results/classifier/gemma3:12b/device/588691 new file mode 100644 index 000000000..aec9105c6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/588691 @@ -0,0 +1,9 @@ + +QEMU is not correctly detecting host CDs + +QEMU's block layer contains code for detecting and using ioctls when real CD-ROM host devices are attached. + +This detection is not working in some host OSes while bad implemented on anothers. + +E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM +E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and the compares it to the constant string "/dev/cdrom". This is useless, that enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X unless manually created by the user. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/588693 b/results/classifier/gemma3:12b/device/588693 new file mode 100644 index 000000000..dc84617c2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/588693 @@ -0,0 +1,4 @@ + +CD-ROM devices always return a one session, one track TOC + +CD-ROM devices always return a one session, one track TOC, no matter if it is using ioctl's with the host or DMG images (both able of having multi track, multi session discs). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/59 b/results/classifier/gemma3:12b/device/59 new file mode 100644 index 000000000..4b41be5b9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/59 @@ -0,0 +1,2 @@ + +ide/core.c ATA Major Version reporting incorrect diff --git a/results/classifier/gemma3:12b/device/591666 b/results/classifier/gemma3:12b/device/591666 new file mode 100644 index 000000000..e574391a1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/591666 @@ -0,0 +1,19 @@ + +broken "pci_add auto storage" + +Doing: +(qemu) pci_add auto storage file=/dev/ram0,if=virtio +Results in: +OK domain 0, bus 0, slot 5, function 0 + +However no device is actually added to the guest. +QEMU: Latest git code (June 9) from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git +(seems to be broken from 0.12.1.2) +KVM: Compiled from git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git +checked out (refs/remotes/origin/stable-2.6.32) + +Both guest and host are Ubuntu 9.10 with 2.6.32 kernel. +Guest kernel has ACPI enabled (specifically, the PCI slot detection driver) + +Guest executed with the following parameters: + -boot c -drive file=/home/eranr/kvm_images/ubuntu-9.10-2.6.32-perf.img,if=ide,boot=on -m 4096 -net nic,model=virtio -net tap,ifname=qtap0,script=no -vnc :0 -smp 1,cores=1,threads=0 -monitor tcp:localhost:6001,server,nowait \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/593 b/results/classifier/gemma3:12b/device/593 new file mode 100644 index 000000000..303e01a6c --- /dev/null +++ b/results/classifier/gemma3:12b/device/593 @@ -0,0 +1,8 @@ + +USB ECM network device does not work under XHCI +Description of problem: +No data is ever received by the USB ECM network device when it is attached to an XHCI controller. (USB 1.0 controllers work OK.) +Additional information: +There are some patches it appears were submitted to the GitHub mirror that resolve the problem (I tested them applied to git master, and confirmed they work): https://github.com/qemu/qemu/pull/100 + +I guess they never were submitted to the mailing list, or somehow got missed? diff --git a/results/classifier/gemma3:12b/device/602544 b/results/classifier/gemma3:12b/device/602544 new file mode 100644 index 000000000..123e04d04 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/603 b/results/classifier/gemma3:12b/device/603 new file mode 100644 index 000000000..efd6039e0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/603 @@ -0,0 +1,2 @@ + +Unable to use mps2-an386 machine with qemu-6.0.0 version code diff --git a/results/classifier/gemma3:12b/device/604 b/results/classifier/gemma3:12b/device/604 new file mode 100644 index 000000000..8dd699c9c --- /dev/null +++ b/results/classifier/gemma3:12b/device/604 @@ -0,0 +1,2 @@ + +QEMU crashes with "-global driver=isa-fdc" diff --git a/results/classifier/gemma3:12b/device/613529 b/results/classifier/gemma3:12b/device/613529 new file mode 100644 index 000000000..d6c2b8162 --- /dev/null +++ b/results/classifier/gemma3:12b/device/613529 @@ -0,0 +1,14 @@ + +qemu does not accept regular disk geometry + +Hi, + +I am currently hunting a strange bug in qemu/kvm: + +I am using an lvm logical volume as a virtual hard disk for a virtual machine. + +I use fdisk or parted to create a partition table and partitions, kpartx to generate the device entries for the partitions, then install linux on ext3/ext4 with grub or msdos filesystem with syslinux. + +But then, in most cases even the boot process fails or behaves strangely, sometimes even mounting the file system in the virtual machine fails. It seems as if there is a problem with the virtual disk geometry. The problem does not seem to occur if I reboot the host system after creating the partition table on the logical volume. I guess the linux kernel needs to learn the disk geometry by reboot. A blkdev --rereadpt does not work on lvm volumes. + +The first approach to test/fix the problem would be to pass the disk geometry to qemu/lvm with the -drive option. Unfortunately, qemu/kvm does not accept the default geometry with 255 heads and 63 sectors. Seems to limit the number of heads to 16, thus limiting the disk size. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/617 b/results/classifier/gemma3:12b/device/617 new file mode 100644 index 000000000..76256aaba --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/62 b/results/classifier/gemma3:12b/device/62 new file mode 100644 index 000000000..f0abb0b4f --- /dev/null +++ b/results/classifier/gemma3:12b/device/62 @@ -0,0 +1,2 @@ + +[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines diff --git a/results/classifier/gemma3:12b/device/626 b/results/classifier/gemma3:12b/device/626 new file mode 100644 index 000000000..031fcf4aa --- /dev/null +++ b/results/classifier/gemma3:12b/device/626 @@ -0,0 +1,2 @@ + +plugin reference to qemu_plugin_hwaddr_phys_addr fails to dynamically link diff --git a/results/classifier/gemma3:12b/device/629 b/results/classifier/gemma3:12b/device/629 new file mode 100644 index 000000000..0b54e45c1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/629 @@ -0,0 +1,11 @@ + +Trying to use EGA or VGA functions from QBASIC doesn't work +Description of problem: +QBASIC can't start any graphics mode beyond CGA + +Some other programs that default to EGA crash trying to start graphics; none that I've tried can start EGA at all; believe to be the same bug; will file separately if it turns out to not be +Steps to reproduce: +1. Boot +2. Start QBASIC +3. Run a program consisting of only "SCREEN 12" for VGA or "SCREEN 9" for EGA +4. Get error message "Illegal Function Call" diff --git a/results/classifier/gemma3:12b/device/634 b/results/classifier/gemma3:12b/device/634 new file mode 100644 index 000000000..3c208ab29 --- /dev/null +++ b/results/classifier/gemma3:12b/device/634 @@ -0,0 +1,82 @@ + +usbredir: assertion failure after suspend/resume when stopped +Description of problem: +Accessing a USB smart card ([Yubikey 5 NFC](https://www.yubico.com/product/yubikey-5-nfc/)) from the guest after host suspend/resume while the guest is stopped and the device is redirected causes QEMU to crash with "Segmentation fault" (with master) or the assertion failure (with Debian 1:6.1+dfsg-5): + + qemu-system-x86_64: ../../hw/usb/core.c:470: usb_packet_complete_one: Assertion `p->stream || QTAILQ_FIRST(&ep->queue) == p' failed. +Steps to reproduce: +1. Run `qemu-system-x86_64` with command line listed above. +2. Run `remote-viewer spice://localhost:3001` in another terminal. +3. Redirect the smart card to the guest in remote-viewer. +4. Run `gpg --card-status` in the guest. +5. Run `stop` in the QEMU monitor. +6. Run `rtcwake --mode mem --seconds 1` as root to suspend the host to S3, then resume. (or `ehco mem >/sys/power/state` or `systemctl suspend` then wake manually) +7. Run `cont` in QEMU monitor to resume the guest. +8. Stop redirecting the smart card to the guest in remote-viewer. +9. Start redirecting the smart card to the guest in remote-viewer. +10. Run `gpg --card-status` in the guest. Repeat if necessary. + +Note that after step 7 the train has left the rails. Executing `gpg --card-status` in the guest at this point would print: + + gpg: selecting card failed: no such device + gpg: OpenPGP card not available: no such device + +However, stopping and resuming redirection appears to be necessary to trigger the assertion failure. + +Also note that on Windows, it's not necessary to execute any `gpg` commands. QEMU will hit the assertion failure after step 9. +Additional information: +<details> +<summary>backtrace with version built from 2c3e83f92d</summary> + + Program terminated with signal SIGSEGV, Segmentation fault. + #0 0x00005623c09a5754 in usb_handle_packet + (dev=0x5623c3592500, p=p@entry=0x7f92e43c81c8) at ../hw/usb/core.c:441 + #1 0x00005623c09be239 in xhci_submit + (epctx=<optimized out>, xfer=<optimized out>, xhci=<optimized out>) + at ../hw/usb/hcd-xhci.c:1783 + #2 xhci_fire_transfer + (epctx=<optimized out>, xfer=<optimized out>, xhci=<optimized out>) + at ../hw/usb/hcd-xhci.c:1792 + #3 xhci_kick_epctx (epctx=0x7f92e43c7c30, streamid=0) + at ../hw/usb/hcd-xhci.c:1951 + #4 0x00005623c09bea1b in xhci_kick_ep + (xhci=<optimized out>, slotid=<optimized out>, epid=<optimized out>, streamid=<optimized out>) at ../hw/usb/hcd-xhci.c:1817 + #5 0x00005623c09bebd8 in xhci_doorbell_write + (ptr=0x7f92ec137970, reg=1, val=4, size=<optimized out>) + at ../hw/usb/hcd-xhci.c:3118 + #6 0x00005623c0abbc7f in memory_region_write_accessor + (mr=mr@entry=0x7f92ec137ed0, addr=4, value=value@entry=0x7f92eda403e8, size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) + at ../softmmu/memory.c:492 + #7 0x00005623c0ab953e in access_with_adjusted_size + (addr=addr@entry=4, value=value@entry=0x7f92eda403e8, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn= + 0x5623c0abbc00 <memory_region_write_accessor>, mr=0x7f92ec137ed0, attrs=...) at ../softmmu/memory.c:554 + #8 0x00005623c0abd650 in memory_region_dispatch_write + (mr=mr@entry=0x7f92ec137ed0, addr=4, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../softmmu/memory.c:1511 + #9 0x00005623c0aad417 in flatview_write_continue + (fv=fv@entry=0x7f92e43c7140, addr=addr@entry=4227932164, attrs=attrs@entry=..., ptr=ptr@entry=0x7f92ef17f028, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, mr=0x7f92ec137ed0) + at /home/kevin/tmp/qemu/include/qemu/host-utils.h:165 + #10 0x00005623c0ab09db in flatview_write + (len=4, buf=0x7f92ef17f028, attrs=..., addr=4227932164, fv=0x7f92e43c7140) + at ../softmmu/physmem.c:2820 + #11 address_space_write + (as=<optimized out>, addr=4227932164, attrs=..., buf=buf@entry=0x7f92ef17f028, len=4) at ../softmmu/physmem.c:2912 + #12 0x00005623c0ab0a9f in address_space_rw + (as=<optimized out>, addr=<optimized out>, attrs=..., + attrs@entry=..., buf=buf@entry=0x7f92ef17f028, len=<optimized out>, is_write=<optimized out>) at ../softmmu/physmem.c:2922 + #13 0x00005623c0ba2890 in kvm_cpu_exec (cpu=cpu@entry=0x5623c2729bc0) + at ../accel/kvm/kvm-all.c:2893 + #14 0x00005623c0ba3bbd in kvm_vcpu_thread_fn (arg=arg@entry=0x5623c2729bc0) + at ../accel/kvm/kvm-accel-ops.c:49 + #15 0x00005623c0d0a959 in qemu_thread_start (args=0x7f92eda40610) + at ../util/qemu-thread-posix.c:557 + #16 0x00007f92fd431eae in start_thread (arg=0x7f92eda45640) + at pthread_create.c:463 + #17 0x00007f92fca2fa5f in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +</details> + +Let me know if there are any additional logs or information that would be useful. + +Thanks,\ +Kevin diff --git a/results/classifier/gemma3:12b/device/639 b/results/classifier/gemma3:12b/device/639 new file mode 100644 index 000000000..5cec4f679 --- /dev/null +++ b/results/classifier/gemma3:12b/device/639 @@ -0,0 +1,2 @@ + +Crash using riscv.shakti.cclass.soc device diff --git a/results/classifier/gemma3:12b/device/641 b/results/classifier/gemma3:12b/device/641 new file mode 100644 index 000000000..2edd3f360 --- /dev/null +++ b/results/classifier/gemma3:12b/device/641 @@ -0,0 +1,2 @@ + +6.1.0 introduces regression in q35, unable to add more than 15 pcie-root-ports diff --git a/results/classifier/gemma3:12b/device/641118 b/results/classifier/gemma3:12b/device/641118 new file mode 100644 index 000000000..68964cec9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/641118 @@ -0,0 +1,11 @@ + +NetBSD guest only supports network without ACPI + +Git commit: abdfd9500e07fab7d6ffd4385fa30a065c329a39 +Host: Linux 64bit Debian +Guest: NetBSD5.0.2/i386 + +Networking works only when ACPI is disabled in the guest. Without it the network card (wm0) is not detected. + +Boot: qemu -hda netbsd5.0.2-i386 -boot c -enable-kvm +Configure: --enable-linux-aio --enable-io-thread --enable-kvm \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/644 b/results/classifier/gemma3:12b/device/644 new file mode 100644 index 000000000..20ccf4b62 --- /dev/null +++ b/results/classifier/gemma3:12b/device/644 @@ -0,0 +1,10 @@ + +generic loader does not do virtual to physical address translation when loading MIPS ELF +Description of problem: + +Steps to reproduce: +1.build two ELFs, whose virtual address is at kseg0<p> +2.load one ELF with generic loader "-device loader,file=test1.elf", the other ELF with "-kernel test2.elf"<p> +3.generic loader loads test1.elf without doing address translation, while mipssim load_kernel will do that with cpu_mips_kseg0_to_phys<p> +Additional information: +generic_loader_realize calls load_elf_as with the argument translate_fn=NULL. Maybe, we can set translate_fn when elf_machine is EM_MIPS. diff --git a/results/classifier/gemma3:12b/device/645524 b/results/classifier/gemma3:12b/device/645524 new file mode 100644 index 000000000..b375138ee --- /dev/null +++ b/results/classifier/gemma3:12b/device/645524 @@ -0,0 +1,4 @@ + +No picture from USB webcam (kvm 0.13-rc1) + +I export my Linux webcam to KVM using the switches "-usb -usbdevice host:046d:0929". The XP guest sees the webcam and the drivers install, but the camera only shows a black image. When I open the camera in Windows Explorer, it says "0 images" and a black image, while on a real XP, it says "1 image" and shows the video from the camera. Same problem with different webcams. Same cameras work fine on a native XP install. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/646 b/results/classifier/gemma3:12b/device/646 new file mode 100644 index 000000000..87ac7b5a1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/648128 b/results/classifier/gemma3:12b/device/648128 new file mode 100644 index 000000000..eb2255e61 --- /dev/null +++ b/results/classifier/gemma3:12b/device/648128 @@ -0,0 +1,166 @@ + +VirtFS: Cannot mount 9p during boot + +I use as client Debian squeeze i386 with a custom kernel: +Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux + +And as host Debian squeeze amd64 +Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux + +kvm version is: +kvm-88-5908-gdd67374 + +Started the client using: +sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel linux-2.6.35.5.qemu -drive file=root.img,if=virtio -net nic,macaddr=02:ca:ff:ee:ba:be,model=virtio,vlan=1 -net tap,ifname=tap1,vlan=1,script=no -virtfs local,path=/host,security_model=passthrough,mount_tag=host -nographic + +I noticed that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using + +mount /mnt + +or + +mount -t 9p -o trans=virtio host /mnt + +(the same stuff i tried inside /etc/rc.local) + +The only output on a failed mount in rc.local/fstab I get is + +[ 15.035920] device: '9p-1': device_add +[ 15.038180] 9p: no channels available +[ 15.038937] device: '9p-1': device_unregister +[ 15.049123] device: '9p-1': device_create_release + +The stuff in /etc/fstab is: +host /mnt 9p trans=virtio 0 0 + + + +I intercepted the boot by adding `set -v; set +e; mount -t 9p -o trans=virtio host_share /mnt; /bin/sh` on top of my /etc/rc.local: +... but than it works quite well... well that is not what I expected. So I changed it to `set -v; mount /mnt || true; /bin/sh`.. and then it doesn't work anymore... mysterios but hey, did you notice that the share is actually called host and not host_share as I wrote inside the rc.local. So why does it work at all? Let me change it to `set -v; set +e; mount -t 9p -o trans=virtio host /mnt; /bin/sh` and reboot again. + +What should i say: it says: +[ 8.004754] device: '9p-1': device_add +[ 8.006446] 9p: no channels available +[ 8.007156] device: '9p-1': device_unregister +[ 8.008650] device: '9p-1': device_create_release +mount: No such file or directory + +But i have a shell now and can type the mount stuff inside it: +$ mount -v -t 9p -o trans=virtio host /mnt +mount -v -t 9p -o trans=virtio host /mnt +[ 70.982688] device: '9p-2': device_add +[ 70.986508] 9p: no channels available +[ 70.987969] device: '9p-2': device_unregister +[ 70.992937] device: '9p-2': device_create_release +mount: No such file or directory +$ ls -l /sys/bus/virtio/drivers/9pnet_virtio +total 0 +--w------- 1 root root 4096 Sep 26 12:58 bind +--w------- 1 root root 4096 Sep 26 12:58 uevent +--w------- 1 root root 4096 Sep 26 12:58 unbind +lrwxrwxrwx 1 root root 0 Sep 26 12:58 virtio1 -> ../../../../devices/virtio-pci/virtio1 +$ ls -l /sys/devices/virtio-pci/virtio1 +total 0 +lrwxrwxrwx 1 root root 0 Sep 26 13:00 bus -> ../../../bus/virtio +-r--r--r-- 1 root root 4096 Sep 26 13:00 device +lrwxrwxrwx 1 root root 0 Sep 26 13:00 driver -> ../../../bus/virtio/drivers/9pnet_virtio +-r--r--r-- 1 root root 4096 Sep 26 13:00 features +-r--r--r-- 1 root root 4096 Sep 26 13:00 modalias +-r--r--r-- 1 root root 4096 Sep 26 13:00 mount_tag +drwxr-xr-x 2 root root 0 Sep 26 12:58 power +-r--r--r-- 1 root root 4096 Sep 26 13:00 status +lrwxrwxrwx 1 root root 0 Sep 26 13:00 subsystem -> ../../../bus/virtio +-rw-r--r-- 1 root root 4096 Sep 26 13:00 uevent +-r--r--r-- 1 root root 4096 Sep 26 13:00 vendor +$ cat /sys/devices/virtio-pci/virtio1/mount_tag +host$ mount -v -t 9p -o trans=virtio host /mnt +[ 340.559853] device: '9p-3': device_add +[ 340.563699] 9p: no channels available +[ 340.565602] device: '9p-3': device_unregister +[ 340.569201] device: '9p-3': device_create_release +mount: No such file or director +$ mount -v -t 9p -o trans=virtio hostA /mnt +[ 406.218462] device: '9p-4': device_add +hostA on /mnt type 9p (rw,trans=virtio) +$ env +CONSOLE=/dev/console +HOME=/ +runlevel=2 +INIT_VERSION=sysvinit-2.88 +COLUMNS=80 +TERM=linux +PATH=/sbin:/usr/sbin:/bin:/usr/bin +RUNLEVEL=2 +PREVLEVEL=N +SHELL=/bin/sh +PWD=/ +previous=N +LINES=24 +VERBOSE=no +$ id +uid=0(root) gid=0(root) groups=0(root) +$ hexdump asd +0000000 6f68 7473 0000 0000 0000 0000 0000 0000 +0000010 0000 0000 +0000014 + +I rebooted again and now just ctrl+d in my rc.local shell to get to my real root login with zsh: +$ cat /sys/devices/virtio-pci/virtio1/mount_tag > asd +$ hexdump asd +0000000 6f68 7473 0000 0000 0000 0000 0000 0000 +0000010 0000 0000 +0000014 +$ id +uid=0(root) gid=0(root) groups=0(root) +$ env +TERM=linux +HOME=/root +SHELL=/bin/zsh +USER=root +LOGNAME=root +PATH=/host/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +MAIL=/var/mail/root +HUSHLOGIN=FALSE +SHLVL=1 +PWD=/root +OLDPWD=/root +COLORTERM=yes +LINKS_XTERM=screen +EDITOR=vim +PAGER=less -r +BROWSER=iceweasel +LESS=-RIM +LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: +HISTFILE=/root/.zsh_history +HISTSIZE=10000 +SAVEHIST=10000 +_=/usr/bin/env +$ mount -v -t 9p -o trans=virtio host /mnt +[ 224.087952] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) + +So the next step was to change my login shell to /bin/sh (dash) and reboot: +$ id +uid=0(root) gid=0(root) groups=0(root) +$ env +USER=root +MAIL=/var/mail/root +OLDPWD=/root +HOME=/root +HUSHLOGIN=FALSE +PS1=\h:\w\$ +LOGNAME=root +TERM=linux +PATH=/host/usr/bin:/host/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +SHELL=/bin/sh +PWD=/host +$ mount -v -t 9p -o trans=virtio host /mnt +[ 15.330643] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) + +Next step was to boot up, change my env and then use the correct mount: +$ for i in USER MAIL OLDPWD HOME HUSHLOGIN PS1 LOGNAME TERM PATH SHELL PWD; do unset $i; done +$ env +$ /bin/mount -v -t 9p -o trans=virtio host /mnt +[ 431.742839] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/65 b/results/classifier/gemma3:12b/device/65 new file mode 100644 index 000000000..db2cad3ab --- /dev/null +++ b/results/classifier/gemma3:12b/device/65 @@ -0,0 +1,2 @@ + +Assigning NVMe disk to a domain causes VFIO_MAP_DMA errors diff --git a/results/classifier/gemma3:12b/device/659 b/results/classifier/gemma3:12b/device/659 new file mode 100644 index 000000000..fa85c7a55 --- /dev/null +++ b/results/classifier/gemma3:12b/device/659 @@ -0,0 +1,42 @@ + +Qemu6 regression causing disabled usb controller upon usbredir device_add +Description of problem: +I'm encountering a nagging issue with usbredir and a windows guest, but although I did pinpoint the commit that caused the issue, I have a hard time understanding it. + +The issue occurs when two usbredir devices are added to a guest windows vm (any vm installed from the official iso will reproduce the issue). When the second device is added, the UHCI usb controller is disabled by windows with an error code 43 (can be seen with in the usb adapters section of the device manager). +Steps to reproduce: +1. take/create an intalled windows image and run it with `qemu-system-x86_64 -M pc -cpu host,hv_time,hv_synic,hv_stimer,hv_vpindex -enable-kvm -m 4096 -device piix3-usb-uhci,id=uhci -qmp tcp:127.0.0.1:4444,server=on,wait=off,ipv4 -drive <disk-parameters> --snapshot` (snapshot not necessary but useful for multiples testing to avoid side effects as the usb status sometime lingers after a shutdown, not sure why) +2. Open windows device manager +3. add devices via [this qmp python script](/uploads/5f2f9240dce1b55ceb148b32f3d6073c/qmp-usb-adds.py) +Additional information: +The commit causing the issue (everything works well when reverting it) is 7bed89958bfbf40df9ca681cefbdca63abdde39d : device_core: use `drain_call_rcu` in in `qmp_device_add`. + +I narrowed the problem to the unlock of the iothread: the minimum `drain_call_rcu` code that still reproduce the issue is: + +```c +void drain_call_rcu(void) +{ + bool locked = qemu_mutex_iothread_locked(); + if (locked) { + qemu_mutex_unlock_iothread(); + } + usleep(50000); // time spent draining the rcu on a few slow cases. + + if (locked) { + qemu_mutex_lock_iothread(); + } +} +``` + +About the qemu command line: The hv parameters are needed to trigger the issue I do not know why. + +I tried to find what was able to take advantage of the free iothread lock, but the only thing I got so far is that the iothread lock is not taken during the first drain (from the first device add), but is taken many times during the second drain by physmem's IOs (from kvm-accel, but at this point, I'm a bit lost). + +I'm looking for pointers as to what could trigger the issue in order to narrow it down, as, so far, I do not understand exactly what causes the regression. +I am unsure of how this would even transcribe in a linux vm so i didn't try to reproduce the issue with one. + +With the attached [reproduction python script](/uploads/5f2f9240dce1b55ceb148b32f3d6073c/qmp-usb-adds.py), the issue triggers nearly 100% of the time. + +Note 1: Related to #650 as the commit causing the regression is the same, although the cause is probably different since the rcu is not implied. + +Note 2: This is a restranscription of [this ml report](https://lore.kernel.org/qemu-devel/20210930134844.f4kh72vpeknr2vmk@gmail.com/) as i wasn't aware, the correct way to report issue was through gitlab now. diff --git a/results/classifier/gemma3:12b/device/662 b/results/classifier/gemma3:12b/device/662 new file mode 100644 index 000000000..1c95b55ef --- /dev/null +++ b/results/classifier/gemma3:12b/device/662 @@ -0,0 +1,12 @@ + +Assertion `!s->do_cmd' failed in am53c974 emulator +Description of problem: + +Steps to reproduce: +``` +1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +2.make -j12 +3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img +``` +Additional information: +# diff --git a/results/classifier/gemma3:12b/device/663 b/results/classifier/gemma3:12b/device/663 new file mode 100644 index 000000000..57815c9d8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/663 @@ -0,0 +1,12 @@ + +Assertion `r->req.aiocb == NULL' in am53c974 emulator +Description of problem: + +Steps to reproduce: +``` +1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +2.make -j12 +3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img +``` +Additional information: +# diff --git a/results/classifier/gemma3:12b/device/665 b/results/classifier/gemma3:12b/device/665 new file mode 100644 index 000000000..e56540f4c --- /dev/null +++ b/results/classifier/gemma3:12b/device/665 @@ -0,0 +1,53 @@ + +Cannot boot from emulated NVMe with seabios +Description of problem: +SeaBIOS doesn't boot from NVMe disk. + +This is regression compared to version 5.1.0. The exact same SeaBIOS binary that works with QEMU 5.1.0, doesn't detect NVMe with QEMU 6.0.0, nor QEMU 6.1.0. Booting from NVMe via OVMF works on all those versions. +Steps to reproduce: +1. Start the above command +2. Press ESC to open boot menu in SeaBIOS +3. Observe lack of NVMe entry +Additional information: +I've bisected it to this commit: +``` +7f0f1acedf159d00684d495d7a14d52220c1d16b is the first bad commit +commit 7f0f1acedf159d00684d495d7a14d52220c1d16b +Author: Klaus Jensen <k.jensen@samsung.com> +Date: Wed Jun 26 08:51:06 2019 +0200 + + hw/block/nvme: support multiple namespaces + + This adds support for multiple namespaces by introducing a new 'nvme-ns' + device model. The nvme device creates a bus named from the device name + ('id'). The nvme-ns devices then connect to this and registers + themselves with the nvme device. + + This changes how an nvme device is created. Example with two namespaces: + + -drive file=nvme0n1.img,if=none,id=disk1 + -drive file=nvme0n2.img,if=none,id=disk2 + -device nvme,serial=deadbeef,id=nvme0 + -device nvme-ns,drive=disk1,bus=nvme0,nsid=1 + -device nvme-ns,drive=disk2,bus=nvme0,nsid=2 + + The drive property is kept on the nvme device to keep the change + backward compatible, but the property is now optional. Specifying a + drive for the nvme device will always create the namespace with nsid 1. + + Signed-off-by: Klaus Jensen <k.jensen@samsung.com> + Reviewed-by: Keith Busch <kbusch@kernel.org> + Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com> + + hw/block/meson.build | 2 +- + hw/block/nvme-ns.c | 167 ++++++++++++++++++++++++++++++++++ + hw/block/nvme-ns.h | 74 +++++++++++++++ + hw/block/nvme.c | 245 ++++++++++++++++++++++++++++++++------------------ + hw/block/nvme.h | 46 +++++----- + hw/block/trace-events | 6 +- + 6 files changed, 426 insertions(+), 114 deletions(-) + create mode 100644 hw/block/nvme-ns.c + create mode 100644 hw/block/nvme-ns.h +``` + +Using `-device nvme-ns` as shown above doesn't help either. diff --git a/results/classifier/gemma3:12b/device/666 b/results/classifier/gemma3:12b/device/666 new file mode 100644 index 000000000..2341cb70f --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/667 b/results/classifier/gemma3:12b/device/667 new file mode 100644 index 000000000..4270d5fca --- /dev/null +++ b/results/classifier/gemma3:12b/device/667 @@ -0,0 +1,2 @@ + +Wacom EMR pen pressure support diff --git a/results/classifier/gemma3:12b/device/669 b/results/classifier/gemma3:12b/device/669 new file mode 100644 index 000000000..e72adddc8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/669 @@ -0,0 +1,24 @@ + +QEMU Segmentation fault - UnRaid 9.3.2 when passing nvidia k620 GPU inserted into Lenovo x3550 M5 server +Description of problem: +When I pass the following GPU to any Virtual Machine: +IOMMU group 33:[10de:13bb] 81:00.0 VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K620] (rev a2) +I receive this error as soon as i try to boot the VM (any OS). + +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: enabling device (0140 -> 0141) +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258 +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +**Oct 13 03:06:12 MyUnraid-1U kernel: qemu-system-x86[6080]: segfault at a8 ip 00005618620c812a sp 00007ffc610531b0 error 4 in qemu-system-x86_64[561861fbb000+51d000] +Oct 13 03:06:12 MyUnraid-1U kernel: Code: ef ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 e8 4e de ff ff 48 89 df e8 16 e9 ff ff <48> 8b 85 a8 00 00 00 48 85 c0 74 52 8b 93 a0 00 00 00 eb 0e 66 90** +Oct 13 03:06:13 MyUnraid-1U avahi-daemon[3536]: Interface vnet0.IPv6 no longer relevant for mDNS. + +This is one example of W10 VM: +In attach my VM template + +[VM_example.txt](/uploads/428ca5a10ef3338d5d408583fc552b25/VM_example.txt) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/670769 b/results/classifier/gemma3:12b/device/670769 new file mode 100644 index 000000000..ececb2b5d --- /dev/null +++ b/results/classifier/gemma3:12b/device/670769 @@ -0,0 +1,15 @@ + +CDROM size not updated when changing image files + +I'm using qemu 13.0 with a plain Linux kernel using the ata_piix driver as the guest, and an initrd that starts a shell. When changing the image in the monitor and reading from the CDROM in the guest, the size is not updated. I'm using LInux 2.6.32.24 +as the host and I've tested 2.6.32.24, 2.6.35, and 2.6.36 as guests. Both host and guest are 64-bit. Here is the command used to start the guest using the initrd: + +./x86_64-softmmu/qemu-system-x86_64 -cdrom /spare2/cd1.img -kernel /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu core2duo + +Additional info on this bug can be found here: http://marc.info/?l=kvm&m=128746013906820&w=2. Note: this is how I discovered +the bug, using 32-bit Slackware install CDs. + +I'm attaching the initrd I used in my tests: I created two different-sized fake CDROM images by dd'ing from /dev/zero. In my tests, +cd1.img is smaller that cd2.img. In the monitor I executed 'change ide1-cd0 /spare2/cd2.img' to load the new image. I checked +the size by cat'ing /sys/block/sr0/size in the guest after reading the CDROM. Reading the CDROM was done by typing +'dd if=/dev/sr0 of=/dev/null bs=512 count=3' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/68 b/results/classifier/gemma3:12b/device/68 new file mode 100644 index 000000000..f8e82fa05 --- /dev/null +++ b/results/classifier/gemma3:12b/device/68 @@ -0,0 +1,2 @@ + +Solaris can't be powered off with ACPI shutdown/poweroff diff --git a/results/classifier/gemma3:12b/device/680 b/results/classifier/gemma3:12b/device/680 new file mode 100644 index 000000000..7c29baabb --- /dev/null +++ b/results/classifier/gemma3:12b/device/680 @@ -0,0 +1,2 @@ + +multi-threaded qemu instance and pci bar diff --git a/results/classifier/gemma3:12b/device/684 b/results/classifier/gemma3:12b/device/684 new file mode 100644 index 000000000..07b361bba --- /dev/null +++ b/results/classifier/gemma3:12b/device/684 @@ -0,0 +1,2 @@ + +xHCI Port Status Change Event at port powered diff --git a/results/classifier/gemma3:12b/device/686613 b/results/classifier/gemma3:12b/device/686613 new file mode 100644 index 000000000..00d2786a4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/69 b/results/classifier/gemma3:12b/device/69 new file mode 100644 index 000000000..8c8df439f --- /dev/null +++ b/results/classifier/gemma3:12b/device/69 @@ -0,0 +1,2 @@ + +ALSA underruns occurr when using QEMU diff --git a/results/classifier/gemma3:12b/device/694 b/results/classifier/gemma3:12b/device/694 new file mode 100644 index 000000000..93389f1e0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/694 @@ -0,0 +1,2 @@ + +Crash using MIPS I7200 CPU with non-nanoMIPS ELF diff --git a/results/classifier/gemma3:12b/device/697510 b/results/classifier/gemma3:12b/device/697510 new file mode 100644 index 000000000..cb277d72c --- /dev/null +++ b/results/classifier/gemma3:12b/device/697510 @@ -0,0 +1,34 @@ + +Machine shut off after tons of lsi_scsi: error: MSG IN data too long + +The problem mostly happens during our backup, syslog does not have any problematic messages. + +Host is Ubuntu 10.10 x86 64 bits +Guest is Windows 2003 Server 32 bits +Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. +Using SCSI the machine shuts off and I get tons of message on stdout; + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 3500 -smp 4,sockets=4,cores=1,threads=1 -name BMSRV0101 -uuid 6ccbb5fa-5880-a1ab-3b7a-fb7ccc7c8ccf -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/BMSRV0101.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/vgUbuntu/vmBMSRV0101,if=none,id=drive-scsi0-0-0,boot=on,format=raw -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:5d:7b:07,bus=pci.0,addr=0x3 -net tap,fd=63,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device usb-host,hostbus=002,hostaddr=005,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +char device redirected to /dev/pts/0 +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +husb: open device 2.5 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 2.5 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 + +lsi_scsi: error: Unimplemented message 0x00 +(x8) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: Unimplemented message 0x00 +(x760) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: MSG IN data too long +kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: Assertion `s->current' failed. + + +I can include minidump file if needed. +I am currently using IDE and it seems OK. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/702 b/results/classifier/gemma3:12b/device/702 new file mode 100644 index 000000000..e65ed8494 --- /dev/null +++ b/results/classifier/gemma3:12b/device/702 @@ -0,0 +1,2 @@ + +Setup a gitlab shared runner for bsd-user testing diff --git a/results/classifier/gemma3:12b/device/705 b/results/classifier/gemma3:12b/device/705 new file mode 100644 index 000000000..37d362fa5 --- /dev/null +++ b/results/classifier/gemma3:12b/device/705 @@ -0,0 +1,28 @@ + +Failed to acpi hotplug on pcie root ports in case of q35+ovmf+machine type 6.1 +Description of problem: +Hotplug on multifunction bridges use ACPI hotplug instead of Native since machine type 6.1 +In this case, Hotplug works well on q35 with bios fireware, But doesn't work on q35 with ovmf firmware. +E.g: +/usr/bin/qemu-system-x86_64 \ +-machine pc-q35-6.1,accel=kvm,pflash0=...... \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ +...... + +(qemu) netdev_add bridge,br=br0,id=hostnet1 +(qemu) device_add virtio-net-pci,netdev=hostnet1,id=net1,bus=pci.3 + +Error message in guest kernel: +kernel: pci 0000:03:00.0: [1af4:1041] type 00 class 0x020000 +kernel: pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x00000fff] +kernel: pci 0000:03:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref] +kernel: pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref] +kernel: pci 0000:03:00.0: BAR 6: no space for [mem size 0x00040000 pref] +kernel: pci 0000:03:00.0: BAR 6: failed to assign [mem size 0x00040000 pref] +kernel: pci 0000:03:00.0: BAR 4: no space for [mem size 0x00004000 64bit pref] +kernel: pci 0000:03:00.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] +kernel: pci 0000:03:00.0: BAR 1: no space for [mem size 0x00001000] +kernel: pci 0000:03:00.0: BAR 1: failed to assign [mem size 0x00001000] +kernel: virtio-pci 0000:03:00.0: virtio_pci: leaving for legacy driver diff --git a/results/classifier/gemma3:12b/device/706 b/results/classifier/gemma3:12b/device/706 new file mode 100644 index 000000000..071f551e2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/706 @@ -0,0 +1,39 @@ + +NVMe End-to-End Data Protection +Description of problem: +When activating end-to-end data protection inside qemu NVMe virtual namespace, guest can not read or write anything to discovered /dev/nvme0n1. Guest kernel has NVMe support compiled-in, when booting i get the following messages related to emulated nvme pi-enabled drive inside guest: + +``` +[ 0.661260] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.663774] Buffer I/O error on dev nvme0n1, logical block 1, async page read +[ 0.665043] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.666976] Buffer I/O error on dev nvme0n1, logical block 0, async page read +[ 0.676702] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.678664] Buffer I/O error on dev nvme0n1, logical block 0, async page read +[ 0.679923] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 0.681811] Buffer I/O error on dev nvme0n1, logical block 1, async page read +[ 0.683544] nvme0n1: unable to read partition table +``` + +Same when trying to read anything: + +``` +/ # dd bs=512 count=1 skip=0 if=/dev/nvme0n1 iflag=direct +[ 432.017616] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 +[ 432.020596] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 432.023530] Buffer I/O error on dev nvme0n1, logical block 0, async page read +[ 432.025345] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +[ 432.028289] Buffer I/O error on dev nvme0n1, logical block 1, async page read +dd: /dev/nvme0n1: Input/output error +``` + +And write: + +``` +/ # dd bs=512 count=1 if=output.dat of=/dev/nvme0n1 +[ 597.679455] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 +dd: error writing '/dev/nvme0n1': Input/output error +1+0 records in +0+0 records out +0 bytes (0B) copied, 0.003864 seconds, 0B/s +``` diff --git a/results/classifier/gemma3:12b/device/708 b/results/classifier/gemma3:12b/device/708 new file mode 100644 index 000000000..2f9426253 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/71 b/results/classifier/gemma3:12b/device/71 new file mode 100644 index 000000000..707b4eb53 --- /dev/null +++ b/results/classifier/gemma3:12b/device/71 @@ -0,0 +1,2 @@ + +AC97 can allocate ~500MB of host RAM diff --git a/results/classifier/gemma3:12b/device/711 b/results/classifier/gemma3:12b/device/711 new file mode 100644 index 000000000..264e41498 --- /dev/null +++ b/results/classifier/gemma3:12b/device/711 @@ -0,0 +1,2 @@ + +ATI Rage video card emulation diff --git a/results/classifier/gemma3:12b/device/716 b/results/classifier/gemma3:12b/device/716 new file mode 100644 index 000000000..68e4a502d --- /dev/null +++ b/results/classifier/gemma3:12b/device/716 @@ -0,0 +1,4 @@ + +using "-device scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/gemma3:12b/device/717 b/results/classifier/gemma3:12b/device/717 new file mode 100644 index 000000000..6f791c3a1 --- /dev/null +++ b/results/classifier/gemma3:12b/device/717 @@ -0,0 +1,4 @@ + +using the "scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/gemma3:12b/device/720 b/results/classifier/gemma3:12b/device/720 new file mode 100644 index 000000000..0cb5e9148 --- /dev/null +++ b/results/classifier/gemma3:12b/device/720 @@ -0,0 +1,2 @@ + +The state of parameter DeviceState *dev in function spapr_get_fw_dev_path of PPC /spapr.c may cause a null pointer reference. diff --git a/results/classifier/gemma3:12b/device/724 b/results/classifier/gemma3:12b/device/724 new file mode 100644 index 000000000..657480328 --- /dev/null +++ b/results/classifier/gemma3:12b/device/724 @@ -0,0 +1,2 @@ + +esp: heap-buffer-overflow in esp_fifo_pop_buf diff --git a/results/classifier/gemma3:12b/device/733 b/results/classifier/gemma3:12b/device/733 new file mode 100644 index 000000000..6fa610a68 --- /dev/null +++ b/results/classifier/gemma3:12b/device/733 @@ -0,0 +1,34 @@ + +Qemu Adventcalendar 2020 ELKS fails to run with error "qemu-system-x86_64: at most one isa-vga device is permitted" +Description of problem: +Running ELKS from Qemu Advent calendar results in: +qemu-system-x86_64: at most one isa-vga device is permitted +Steps to reproduce: +(with ELKS) +1. Untar https://download.qemu.org/qemu-6.2.0-rc0.tar.xz +1. Build qemu-system-x86_64 +2. Download https://www.qemu-advent-calendar.org/2020/download/day23.tar.gz +3. Execute ELKS as described in run.sh +Additional information: +A git bisect was performed to identify the culprit commit: +``` +qemu$ git bisect good +binäre Suche: danach noch 1 Commit zum Testen übrig (ungefähr 1 Schritt) +[2b3a98255c90d8d2f9f87a73eb33371961508517] hw/display/xlnx_dp: fix an out-of-bounds read in xlnx_dp_read + +qemu$ ./configure --target-list=x86_64-softmmu --disable-linux-user && make -j2 + +qemu$ build/qemu-system-x86_64 -machine isapc -vga std +qemu-system-x86_64: at most one isa-vga device is permitted + +qemu$ git bisect bad +binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 0 Schritte) +[7852a77f598635a67a222b6c1463c8b46098aed2] vga: don't abort when adding a duplicate isa-vga device + +qemu$ cat .git/refs/bisect/bad +2b3a98255c90d8d2f9f87a73eb33371961508517 + +qemu$ git status +HEAD losgelöst bei 7852a77f59 + +``` diff --git a/results/classifier/gemma3:12b/device/736 b/results/classifier/gemma3:12b/device/736 new file mode 100644 index 000000000..547796fbf --- /dev/null +++ b/results/classifier/gemma3:12b/device/736 @@ -0,0 +1,48 @@ + +qemu-system-arm crash (hardware error: tsc210x_txrx: FIXME: bad SPI word width 24) +Description of problem: +The `tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800` will sometimes trigger situation where the test does not progress and ends up interrupted. One example is [here](https://gitlab.com/qemu-project/qemu/-/jobs/1796742618#L242): + +``` +(075/171) tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800: INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred: Timeout reached\nOriginal status: ERROR\n{'name': '075-tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800', 'logdir': '/builds/qem +``` +Steps to reproduce: +1. ./tests/venv/bin/avocado assets fetch tests/avocado/machine_arm_n8x0.py +2. nc -l -U /var/tmp/qemu-monitor.sock +3. ./qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/qemu-monitor.sock -mon chardev=mon,mode=control -machine n800 -serial null -chardev socket,id=console,path=/var/tmp/qemu-51887-console.sock,server=on,wait=off -serial chardev:console -kernel $HOME/avocado/data/cache/by_location/07af9de13713c2905e8c6a88d6600eb1bc885c5c/meego-arm-n8x0-1.0.80.20100712.1431-vmlinuz-2.6.35~rc4-129.1-n8x0 -append 'printk.time=0 console=ttyS1' +Additional information: +``` +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 +#1 0x00007ffff4d498c3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 +#2 0x00007ffff4cfc6b6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007ffff4ce67d3 in __GI_abort () at abort.c:79 +#4 0x0000555555e544b3 in hw_error (fmt=0x555556264da8 "%s: FIXME: bad SPI word width %i\n") at ../../src/qemu/softmmu/cpus.c:126 +#5 0x0000555555a8f4b8 in tsc210x_txrx (opaque=0x5555579e9820, value=6468416, len=24) at ../../src/qemu/hw/input/tsc210x.c:913 +#6 0x0000555555bf49c1 in omap_mcspi_transfer_run (s=0x555557757d10, chnum=0) at ../../src/qemu/hw/ssi/omap_spi.c:93 +#7 0x0000555555bf536b in omap_mcspi_write (opaque=0x555557757d10, addr=56, value=6468416, size=4) at ../../src/qemu/hw/ssi/omap_spi.c:335 +#8 0x0000555555e68f05 in memory_region_write_accessor + (mr=0x555557757d10, addr=56, value=0x7fffe7034cc8, size=4, shift=0, mask=4294967295, attrs=...) at ../../src/qemu/softmmu/memory.c:492 +#9 0x0000555555e6914b in access_with_adjusted_size (addr=56, value=0x7fffe7034cc8, size=4, access_size_min=1, access_size_max=4, access_fn= + 0x555555e68e0f <memory_region_write_accessor>, mr=0x555557757d10, attrs=...) at ../../src/qemu/softmmu/memory.c:554 +#10 0x0000555555e6c1e4 in memory_region_dispatch_write (mr=0x555557757d10, addr=56, data=6468416, op=MO_32, attrs=...) + at ../../src/qemu/softmmu/memory.c:1504 +#11 0x0000555555fa9936 in io_writex + (env=0x555556e419f0, iotlbentry=0x7fff581ad800, mmu_idx=10, val=6468416, addr=4194926648, retaddr=140734913962650, op=MO_32) + at ../../src/qemu/accel/tcg/cputlb.c:1420 +#12 0x0000555555fac1b1 in store_helper (env=0x555556e419f0, addr=4194926648, val=6468416, oi=42, retaddr=140734913962650, op=MO_32) + at ../../src/qemu/accel/tcg/cputlb.c:2355 +#13 0x0000555555fac571 in full_le_stl_mmu (env=0x555556e419f0, addr=4194926648, val=6468416, oi=42, retaddr=140734913962650) + at ../../src/qemu/accel/tcg/cputlb.c:2443 +#14 0x0000555555fac5a9 in helper_le_stl_mmu (env=0x555556e419f0, addr=4194926648, val=6468416, oi=42, retaddr=140734913962650) + at ../../src/qemu/accel/tcg/cputlb.c:2449 +#15 0x00007fff668de29a in code_gen_buffer () +#16 0x0000555555f95c5d in cpu_tb_exec (cpu=0x555556e37c60, itb=0x7fffa3aae140, tb_exit=0x7fffe703540c) at ../../src/qemu/accel/tcg/cpu-exec.c:357 +#17 0x0000555555f96afe in cpu_loop_exec_tb (cpu=0x555556e37c60, tb=0x7fffa3aae140, last_tb=0x7fffe7035420, tb_exit=0x7fffe703540c) + at ../../src/qemu/accel/tcg/cpu-exec.c:833 +#18 0x0000555555f96ed7 in cpu_exec (cpu=0x555556e37c60) at ../../src/qemu/accel/tcg/cpu-exec.c:992 +#19 0x0000555555fb9682 in tcg_cpus_exec (cpu=0x555556e37c60) at ../../src/qemu/accel/tcg/tcg-accel-ops.c:67 +#20 0x0000555555fb9a13 in mttcg_cpu_thread_fn (arg=0x555556e37c60) at ../../src/qemu/accel/tcg/tcg-accel-ops-mttcg.c:95 +#21 0x0000555556179831 in qemu_thread_start (args=0x55555700dbc0) at ../../src/qemu/util/qemu-thread-posix.c:556 +#22 0x00007ffff4d47b17 in start_thread (arg=<optimized out>) at pthread_create.c:435 +#23 0x00007ffff4dcc6c0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/gemma3:12b/device/74 b/results/classifier/gemma3:12b/device/74 new file mode 100644 index 000000000..c608b62b7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/74 @@ -0,0 +1,2 @@ + +AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut diff --git a/results/classifier/gemma3:12b/device/740895 b/results/classifier/gemma3:12b/device/740895 new file mode 100644 index 000000000..00c60955a --- /dev/null +++ b/results/classifier/gemma3:12b/device/740895 @@ -0,0 +1,65 @@ + +qemu freeze when loading msdos with EMM386.EXE NOEMS HIGHSCAN + +Qemu version used : 0.11.2 and 0.14.0 +Guest : Ms-Dos 6.2 +Host : Ubuntu 10.04 with 2.6.32-29-generic SMP i686 +Starting Qemu with command : qemu -hda dos.img -cpu 486 -m 16 + +When I start msDos under Qemu with the option (in CONFIG.SYS) +DEVICE=C:\DOS\EMM386.EXE NOEMS HIGHSCAN +the guest freeze. +If I remove "HIGHSCAN" system is booting (but my software is not working). + +The whole thing is working on a real computer with a 486 with 16Mb ram or a PII. + +"HIGHSCAN switch allows EMM386.EXE to map expanded memory pages or upper memory blocks (UMBs) over portions of the upper memory area (UMA) used by system read-only memory " from http://support.microsoft.com/kb/96522/en-us + +I add some traces inside "default_ioport_read" in ioport.c, but I don't see any access to F000h-F7FFh like said in ms help. + +Before the system hung, there is access to dma1, dma page register and dma2 : + +inb : 0087 00 +outb: 000c 00 +inb : 0000 00 +inb : 0000 00 +inb : 0001 00 +inb : 0001 00 +inb : 0083 00 +outb: 000c 00 +inb : 0002 00 +inb : 0002 00 +inb : 0003 00 +inb : 0003 00 +inb : 0081 00 +outb: 000c 00 +inb : 0004 00 +inb : 0004 00 +inb : 0005 00 +inb : 0005 00 +inb : 0082 00 +outb: 000c 00 +inb : 0006 00 +inb : 0006 00 +inb : 0007 00 +inb : 0007 00 +inb : 008b 00 +outb: 00d8 00 +inb : 00c4 00 +inb : 00c4 00 +inb : 00c6 00 +inb : 00c6 00 +inb : 0089 00 +outb: 00d8 00 +inb : 00c8 00 +inb : 00c8 00 +inb : 00ca 00 +inb : 00ca 00 +inb : 008a 00 +outb: 00d8 00 +inb : 00cc 00 +inb : 00cc 00 +inb : 00ce 00 +inb : 00ce 00 +outb: 000c 00 +outb: 00d8 00 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/752 b/results/classifier/gemma3:12b/device/752 new file mode 100644 index 000000000..83f7300ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/752 @@ -0,0 +1,14 @@ + +vmmouse device gets attached twice, one without i8042 associated +Description of problem: +I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too. + +[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is: + +* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time +* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler +* obviously, a crash because ISAKBDDevice should never be null +Steps to reproduce: +1. Load VMware mouse driver +2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading) +3. Crash diff --git a/results/classifier/gemma3:12b/device/757 b/results/classifier/gemma3:12b/device/757 new file mode 100644 index 000000000..e9f82d7f4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/757 @@ -0,0 +1,2 @@ + +intel-hda: stream reset bits are broken diff --git a/results/classifier/gemma3:12b/device/757654 b/results/classifier/gemma3:12b/device/757654 new file mode 100644 index 000000000..1ecd9b377 --- /dev/null +++ b/results/classifier/gemma3:12b/device/757654 @@ -0,0 +1,16 @@ + +UHCI fails to signal stall response + +When TD execution results in STALL error (STALL handshake, no stall as a result of err count reaching 0), there is no way to know about it except for checking that TD. IMO it is an error condition and it should be reflected in the status register (and issue an interrupt if enabled). + +Ways to replicate: +Send a query that is answered by stall (like set_idle request to a mouse) + +Expected behavior: +UHCI hc sets status bit 1 (usb error interrupt) and issues an interrupt + +current behavior: +Neither status bit is set nor interrupt triggered + +Version 0.14 +attached patch for current master (quick fix, it might be I got something wrong) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/764252 b/results/classifier/gemma3:12b/device/764252 new file mode 100644 index 000000000..68b91a4a8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/764252 @@ -0,0 +1,4 @@ + +wishlist: kirkwood support + +This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/770 b/results/classifier/gemma3:12b/device/770 new file mode 100644 index 000000000..2c2540aef --- /dev/null +++ b/results/classifier/gemma3:12b/device/770 @@ -0,0 +1,2 @@ + +READ memory access in /hw/acpi/pcihp.c diff --git a/results/classifier/gemma3:12b/device/778 b/results/classifier/gemma3:12b/device/778 new file mode 100644 index 000000000..8c291c476 --- /dev/null +++ b/results/classifier/gemma3:12b/device/778 @@ -0,0 +1,2 @@ + +heap-buffer-overflow in megasas_sgl_get_len diff --git a/results/classifier/gemma3:12b/device/78 b/results/classifier/gemma3:12b/device/78 new file mode 100644 index 000000000..c126a0d26 --- /dev/null +++ b/results/classifier/gemma3:12b/device/78 @@ -0,0 +1,2 @@ + +msmouse serial mouse emulation broken? No id byte sent on reset diff --git a/results/classifier/gemma3:12b/device/781 b/results/classifier/gemma3:12b/device/781 new file mode 100644 index 000000000..4432c6717 --- /dev/null +++ b/results/classifier/gemma3:12b/device/781 @@ -0,0 +1,2 @@ + +Assertion `addr < cache->len && 2 <= cache->len - addr' failed in address_space_stw_le_cached diff --git a/results/classifier/gemma3:12b/device/782 b/results/classifier/gemma3:12b/device/782 new file mode 100644 index 000000000..a2669b182 --- /dev/null +++ b/results/classifier/gemma3:12b/device/782 @@ -0,0 +1,6 @@ + +nvme: DMA reentrancy issue leads to use-after-free (CVE-2021-3929) +Description of problem: +A DMA reentrancy issue was found in the NVM Express Controller (NVMe) emulation. Functions dma_buf_write() or dma_buf_read() in hw/nvme/ctrl.c:nvme_tx() can be called without checking if the destination region overlaps with device's MMIO. This is similar to CVE-2021-3750 (https://gitlab.com/qemu-project/qemu/-/issues/541) and, just like it, when the reentrancy write triggers the reset function nvme_ctrl_reset(), data structs will be freed leading to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host. + +This issue was reported by Qiuhao Li. diff --git a/results/classifier/gemma3:12b/device/786 b/results/classifier/gemma3:12b/device/786 new file mode 100644 index 000000000..f0d97e0f8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/786 @@ -0,0 +1,18 @@ + +assert in qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) +Description of problem: +assert and crash when -acpitable argument is used. Specifically, the argument was "-acpitable file=my_file.bin" which causes the assert and crash. + +The other arguments, I hope, are not critical. In brief, I'm using secure boot (with ovmf_code.secboot.fd), and a sw tpm as well. But hopefully these are not relevant. + +The assert with -acpitable is a regression since it worked with version 6.1.0 + +The actual error message in qemu 6.2.0 is + +qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/device/786208 b/results/classifier/gemma3:12b/device/786208 new file mode 100644 index 000000000..c9f96e5eb --- /dev/null +++ b/results/classifier/gemma3:12b/device/786208 @@ -0,0 +1,10 @@ + +Missing checks for non-existent device in ide_exec_cmd + +Several calls in the ide_exec_cmd handler are missing checks for (!s->bs) or similar, resulting in NULL pointer dereferences, divide-by-zero, or possibly other badness if the guest performs operations on a non-existent IDE master. + +For example, the WIN_READ_NATIVE_MAX command does a 'ide_set_sector(s, s->nb_sectors - 1);', which does 'cyl = sector_num / (s->heads * s->sectors);', which will fail with a divide-by-zero if heads = sectors = 0. + +And WIN_MULTREAD also does not check for s->bs, but does a 'ide_sector_read(s);', which will do 'bdrv_read(s->bs, sector_num, s->io_buffer, n);' on a NULL s->bs, leading to a segfault. + +I do not *believe* that a malicious guest can do anything more than cause a crash with these bugs. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/786209 b/results/classifier/gemma3:12b/device/786209 new file mode 100644 index 000000000..05ee4967d --- /dev/null +++ b/results/classifier/gemma3:12b/device/786209 @@ -0,0 +1,8 @@ + +Information leak in IDE core + +When the DRQ_STAT bit is set, the IDE core permits both data reads and data writes, regardless of whether the current transfer was initiated as a read or write. + +Furthermore, the IO buffer is allocated via a qemu_memalign but not initialized or cleared at device creation. + +This potentially leaks uninitialized host memory into the guest, if, before doing anything else to an IDE device, the guest begins a write transaction (e.g. WIN_WRITE), but then *reads* from the IO port instead of writing to it. The IDE core will happily return the uninitialized contents of the buffer to the guest, potentially leaking offsets that could be used as part of an attack to get around ASLR. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/787 b/results/classifier/gemma3:12b/device/787 new file mode 100644 index 000000000..5b2842295 --- /dev/null +++ b/results/classifier/gemma3:12b/device/787 @@ -0,0 +1,13 @@ + +6.2.0 Regression with Intel GVT-g +Description of problem: +Until version 6.1.0 the Intel GVT-g graphics passtrought was working flawless. But, since the version 6.2.0 the machine with the exact same configuration is not working anymore, presenting an error that the graphics device was not found. + +``` +qemu-system-x86_64: -set device.hostdev0.x-igd-opregion=on: there is no device "hostdev0" defined +``` + +Downgrade to 6.1.0 fixes the problem. +Steps to reproduce: +1. Create a virtual machine with GVT-g +2. Try to run the machine. diff --git a/results/classifier/gemma3:12b/device/793 b/results/classifier/gemma3:12b/device/793 new file mode 100644 index 000000000..3d9818f4e --- /dev/null +++ b/results/classifier/gemma3:12b/device/793 @@ -0,0 +1,2 @@ + +Wrong pci express bus type - qemu 6.1.0-5 diff --git a/results/classifier/gemma3:12b/device/795 b/results/classifier/gemma3:12b/device/795 new file mode 100644 index 000000000..e7d6b1e06 --- /dev/null +++ b/results/classifier/gemma3:12b/device/795 @@ -0,0 +1,2 @@ + +meson.build: coreaudio check failed diff --git a/results/classifier/gemma3:12b/device/800 b/results/classifier/gemma3:12b/device/800 new file mode 100644 index 000000000..1d4f654d8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/800 @@ -0,0 +1,26 @@ + +Cannot write to MTP Devices in Qemu 6.0.0+ +Description of problem: +QEMU versions above 6.0.0 are no longer able to write to MTP devices, the kernel prints a warning which is unique to versions above 6.0.0: +``` +usb-mtp: file monitoring init failed: File monitoring not available on this platform is just warning +``` +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: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + touch mtpDevice/test + ``` +4. Observe that you will get an input/output error when trying to write to the device, like this: + ``` + vm-test-run-mtp> client: must succeed: /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh >&2 + vm-test-run-mtp> client # Device 0 (VID=46f4 and PID=0004) is a QEMU Virtual MTP. + vm-test-run-mtp> client # qemu-system-x86_64: usb-mtp: file monitoring init failed: File monitoring not available on this platform + vm-test-run-mtp> client # /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh: line 4: phone/tmp/testFile: Input/output error + ``` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/802 b/results/classifier/gemma3:12b/device/802 new file mode 100644 index 000000000..dc9179d65 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/803 b/results/classifier/gemma3:12b/device/803 new file mode 100644 index 000000000..671c060f8 --- /dev/null +++ b/results/classifier/gemma3:12b/device/803 @@ -0,0 +1,21 @@ + +v6.2.0 armv7m: savevm fails assertion +Description of problem: +Trying to take a snapshot on some arm machines just fails an assertion, while some work fine. +e.g. mps2-an385 and stm32vldiscovery don't work, while e.g. raspi0 does. +``` +$ build/qemu-system-arm -machine mps2-an385 -monitor stdio -drive file=dummy.qcow2 -S +QEMU 6.1.50 monitor - type 'help' for more information +(qemu) VNC server running on ::1:5900 +savevm test +qemu-system-arm: ../migration/vmstate.c:363: vmstate_save_state_v: Assertion `first_elem || !n_elems || !size' failed. +[1] 631940 IOT instruction (core dumped) build/qemu-system-arm -machine mps2-an385 -monitor stdio -drive -S +``` +This happens with or without a kernel (so -S is optional, if a kernel is present). +Steps to reproduce: +1. Create some image for snapshots (once): ``qemu-img create -f qcow2 dummy.qcow2 32M`` +2. ``qemu-system-arm -machine mps2-an385 -monitor stdio -drive file=dummy.qcow2 -S`` +3. In monitor: ``savevm something`` +Additional information: +Bisect indicates the Problem first presented itself in commit d5093d961585f02126191951ded9b90dbc52883b by @pm215. +This led me to test stm32vldiscovery, which also includes armv7m.h and fails, while some others don't. diff --git a/results/classifier/gemma3:12b/device/804 b/results/classifier/gemma3:12b/device/804 new file mode 100644 index 000000000..40bd67f6b --- /dev/null +++ b/results/classifier/gemma3:12b/device/804 @@ -0,0 +1,10 @@ + +savevm - QXL preventing save +Description of problem: +Attempting to savevm with a QXL VGA device attached causes the error "pre-save failed: qxl" to appear. +Steps to reproduce: +1. Start a QEMU instance with a QXL device +2. Attempt to savevm +3. See error +Additional information: + diff --git a/results/classifier/gemma3:12b/device/811 b/results/classifier/gemma3:12b/device/811 new file mode 100644 index 000000000..774f17f56 --- /dev/null +++ b/results/classifier/gemma3:12b/device/811 @@ -0,0 +1,2 @@ + +qemu_irq_split() callers should use TYPE_SPLIT_IRQ device instead diff --git a/results/classifier/gemma3:12b/device/818673 b/results/classifier/gemma3:12b/device/818673 new file mode 100644 index 000000000..768109f43 --- /dev/null +++ b/results/classifier/gemma3:12b/device/818673 @@ -0,0 +1,9 @@ + +virtio: trying to map MMIO memory + +Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +Qemu is started as such: +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/822408 b/results/classifier/gemma3:12b/device/822408 new file mode 100644 index 000000000..4353ec203 --- /dev/null +++ b/results/classifier/gemma3:12b/device/822408 @@ -0,0 +1,46 @@ + +Unable to access disk image on mipsel host + +Something is wrong with hard disk images on MIPSel host. + +The host system is mips64el (Loongson cpu, Linux 2.6.39, eglibc 2.13) +Tried Qemu 0.14.1 and 0.15.0-rc2, both compiled with GCC 4.6.0. + +First I was trying to install WinXP (i386-softmmu). +Starting install, create partition, format (either quick and full), seems to complete, boom the error: + +" +Setup was unable to format the partition. The disk may be damaged. Make sure the drive is switched on and properly connected to your computer. If the disk is a SCSI disk, make sure your SCSI devices are properly terminated. Consult your computer manual or SCSI adapter documentation for more information. + +You must select a different partition for Windows XP. +To continue, press ENTER. +" + +This happens with both raw and qcow2 image format. +Tried 10Gb image, tried 16Gb one - no difference. + +On a x86 host, that formatting makes the image (qcow2) grow to about 81 Mb by the time it reaches 100% formatted (quick), but on mipsel it grows to 0.8Mb at the same time and the error appears. + +I tried the same installing of Windows in Qemu on x86 host and copied over the completed image. +In that case it starts loading, but in the middle of the animation there is an error: + +" +STOP: c0000221 Unknown Hard Error +\Systemroot\System32\ntdll.dll +" +(or HAL.dll) + +So, i tried linux-0.2.img.bz2 from the Qemu site, and that fails too. +Thus it's the minimal bug reproduction thing. + +During boot there are multiple errors like: +" +hda: dma_intr: status=0x41 { DriveReady Error } +hda: dma_intr: error=0x04 { DriveStatusError } +hda: Failed opcode was: unknown +" + +It booted and kind of worked, there were weird glitches in every program. +Unusable. + +Summarily, that suggest some error in hard disk emulation or back storage, specific either to MIPSel or non-x86 hosts. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/825776 b/results/classifier/gemma3:12b/device/825776 new file mode 100644 index 000000000..05e3d6256 --- /dev/null +++ b/results/classifier/gemma3:12b/device/825776 @@ -0,0 +1,15 @@ + +-boot -hda //.//physicaldrivex does not work if it is USB drive + +qemu-system-x86_64.exe -L . -name "RMPrepUSB Emulation Session" -boot c -m 500 -hda //./PhysicalDrive1 + +just opens a blank QEMU window (no BIOS POSt messages) and does nothing + +qemu v 0.15.0 +Under Windows 7 64-bit +drive1 is a USB Flash drive + +Previous version of x86_64 (Jan 2010) works fine. If replace with new version (or RC2 version) then does not work. + +if use harddisk.img raw file instead of USB physical device then I get BIOS POST messages and it boots to image OK. +So appears to be USB or physicaldisk support issue??? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/826 b/results/classifier/gemma3:12b/device/826 new file mode 100644 index 000000000..ac68c90dc --- /dev/null +++ b/results/classifier/gemma3:12b/device/826 @@ -0,0 +1,17 @@ + +AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated +Description of problem: +During execution of the following SVE2 instruction: +`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` +with the following register state: +``` +(gdb) p $p3 +$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} +(gdb) p $z14.d.u +$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} +(gdb) p $x9 +$3 = 0x0 +``` +QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. +Additional information: +A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/gemma3:12b/device/827 b/results/classifier/gemma3:12b/device/827 new file mode 100644 index 000000000..171d4ac9c --- /dev/null +++ b/results/classifier/gemma3:12b/device/827 @@ -0,0 +1,2 @@ + +Stack-overflow through virtio_blk_get_request diff --git a/results/classifier/gemma3:12b/device/830 b/results/classifier/gemma3:12b/device/830 new file mode 100644 index 000000000..8972a2441 --- /dev/null +++ b/results/classifier/gemma3:12b/device/830 @@ -0,0 +1,2 @@ + +QEMU aarch64 support for Windows TPM driver (TIS, CRB interfaces) diff --git a/results/classifier/gemma3:12b/device/838 b/results/classifier/gemma3:12b/device/838 new file mode 100644 index 000000000..c2fc621cc --- /dev/null +++ b/results/classifier/gemma3:12b/device/838 @@ -0,0 +1,2 @@ + +qemu-system-arm, ast2600-evb, the address mapping of ASPEED_DEV_SPI2 is different from datasheet diff --git a/results/classifier/gemma3:12b/device/84 b/results/classifier/gemma3:12b/device/84 new file mode 100644 index 000000000..c3ac9f4dd --- /dev/null +++ b/results/classifier/gemma3:12b/device/84 @@ -0,0 +1,2 @@ + +Machine shut off after tons of lsi_scsi: error: MSG IN data too long diff --git a/results/classifier/gemma3:12b/device/847 b/results/classifier/gemma3:12b/device/847 new file mode 100644 index 000000000..5131dae1b --- /dev/null +++ b/results/classifier/gemma3:12b/device/847 @@ -0,0 +1,31 @@ + +rdhpr %htstate unimplemented in translator +Description of problem: +I accidentally mixed up a copy of T1 and T2 sun4v firmwares and was able to trigger the following TCG assert ``tcg_reg_alloc_mov: Assertion `ts->val_type == TEMP_VAL_REG' failed.`` upon boot. + +Having discovered my mistake I was expecting the guest to crash at some point but without triggering an +assert. +Steps to reproduce: +1. Download the attached file bug.tar.gz and extract it + +2. Apply the following diff to update the UART address for the T2 firmware + +``` +diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c +index ccad2c43a3..7af64bd50f 100644 +--- a/hw/sparc64/niagara.c ++++ b/hw/sparc64/niagara.c +@@ -51,7 +51,7 @@ typedef struct NiagaraBoardState { + + #define NIAGARA_PARTITION_RAM_BASE 0x80000000ULL + +-#define NIAGARA_UART_BASE 0x1f10000000ULL ++#define NIAGARA_UART_BASE 0xfff0c2c000ULL + + #define NIAGARA_NVRAM_BASE 0x1f11000000ULL + #define NIAGARA_NVRAM_SIZE 0x2000 +``` + +3. Run `./qemu-system-sparc64 -M niagara -L ./bug/ -m 256 -nographic` +Additional information: + diff --git a/results/classifier/gemma3:12b/device/850 b/results/classifier/gemma3:12b/device/850 new file mode 100644 index 000000000..d78ce89d9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/850 @@ -0,0 +1,60 @@ + +virtio-gpu: bogus descriptor or out of resources +Description of problem: +The guest which I use have 1GB memory, also the guest contains 8GB swap, when I open lot of applications in the guest, the guest kernel starts using swap, after some time, I get this error + +<code> +qemu-system-x86_64: virtio: bogus descriptor or out of resources +</code> + +I tried to see which virtio device causing this issue, it seems this issue is happening in "virtio-gpu", I modified the sources ad added this line to see the device name + +virtio.c:1312: virtio_error(vdev, "virtio: %s: bogus descriptor or out of resources", vdev->name); +Steps to reproduce: +1. create a vm with 8GB swap +2. run that vm with above mentioned commandline (memory = 1MB) +3. open huge applications which eats ram in guest +Additional information: +Seems suddenly condition "if (!memory_access_is_direct(mr, is_write))" [physmem.c:1385] becomes true, this is the stack trace when "if (qatomic_xchg(&bounce.in_use, true)) {" [physmem.c:1386] line gets hit for the first time, + +<code> +#0 address_space_map (as=<optimized out>, addr=addr@entry=45251811299328, plen=plen@entry=0x7fffffff7e30, is_write=is_write@entry=false, attrs=..., attrs@entry=...) at ../qemu-6.2.0/softmmu/physmem.c:3186 +#1 0x0000555555cb8cf4 in dma_memory_map (dir=DMA_DIRECTION_TO_DEVICE, len=<synthetic pointer>, addr=45251811299328, as=<optimized out>) at /home/mohan/Downloads/qemu/src/qemu-6.2.0/include/sysemu/dma.h:202 +#2 virtqueue_map_desc + (vdev=vdev@entry=0x5555579d3bb0, p_num_sg=p_num_sg@entry=0x7fffffff7ed8, addr=addr@entry=0x7fffffff7f70, iov=0x7fffffff9f70, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=45251811299328, sz=65536) at ../qemu-6.2.0/hw/virtio/virtio.c:1307 +#3 0x0000555555cb8f9e in virtqueue_packed_pop (vq=<optimized out>, sz=<optimized out>) at ../qemu-6.2.0/hw/virtio/virtio.c:1624 +#4 0x00007fffec0b329e in virtio_gpu_gl_handle_ctrl (vdev=<optimized out>, vq=0x7fffdced6010) at ../qemu-6.2.0/hw/display/virtio-gpu-gl.c:77 +#5 0x0000555555f74134 in aio_bh_call (bh=0x555556d02bc0) at ../qemu-6.2.0/util/async.c:141 +#6 aio_bh_poll (ctx=ctx@entry=0x555556958750) at ../qemu-6.2.0/util/async.c:169 +#7 0x0000555555f5f784 in aio_dispatch (ctx=0x555556958750) at ../qemu-6.2.0/util/aio-posix.c:381 +#8 0x0000555555f73d63 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311 +#9 0x00007ffff787dfd3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 +#10 0x0000555555f80129 in glib_pollfds_poll () at ../qemu-6.2.0/util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=0) at ../qemu-6.2.0/util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../qemu-6.2.0/util/main-loop.c:531 +#13 0x0000555555c48fe5 in qemu_main_loop () at ../qemu-6.2.0/softmmu/runstate.c:726 +#14 0x000055555597b664 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../qemu-6.2.0/softmmu/main.c:50 +</code> +<br/> +address_space_map() returns valid pointer in the first hit, but it returns NULL on the second hit because qatomic_xchg(bounce.in_use, true) returns true, I think it should suppose to return false. this is the stack trace when it happens for the second time +<br/> +<code> +#0 address_space_map (as=<optimized out>, addr=addr@entry=45251811303424, plen=plen@entry=0x7fffffff7e30, is_write=is_write@entry=false, attrs=..., attrs@entry=...) at ../qemu-6.2.0/softmmu/physmem.c:3186 +#1 0x0000555555cb8cf4 in dma_memory_map (dir=DMA_DIRECTION_TO_DEVICE, len=<synthetic pointer>, addr=45251811303424, as=<optimized out>) at /home/mohan/Downloads/qemu/src/qemu-6.2.0/include/sysemu/dma.h:202 +#2 virtqueue_map_desc + (vdev=vdev@entry=0x5555579d3bb0, p_num_sg=p_num_sg@entry=0x7fffffff7ed8, addr=addr@entry=0x7fffffff7f70, iov=0x7fffffff9f70, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=45251811303424, sz=61440) at ../qemu-6.2.0/hw/virtio/virtio.c:1307 +#3 0x0000555555cb8f9e in virtqueue_packed_pop (vq=<optimized out>, sz=<optimized out>) at ../qemu-6.2.0/hw/virtio/virtio.c:1624 +#4 0x00007fffec0b329e in virtio_gpu_gl_handle_ctrl (vdev=<optimized out>, vq=0x7fffdced6010) at ../qemu-6.2.0/hw/display/virtio-gpu-gl.c:77 +#5 0x0000555555f74134 in aio_bh_call (bh=0x555556d02bc0) at ../qemu-6.2.0/util/async.c:141 +#6 aio_bh_poll (ctx=ctx@entry=0x555556958750) at ../qemu-6.2.0/util/async.c:169 +#7 0x0000555555f5f784 in aio_dispatch (ctx=0x555556958750) at ../qemu-6.2.0/util/aio-posix.c:381 +#8 0x0000555555f73d63 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311 +#9 0x00007ffff787dfd3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 +#10 0x0000555555f80129 in glib_pollfds_poll () at ../qemu-6.2.0/util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=0) at ../qemu-6.2.0/util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../qemu-6.2.0/util/main-loop.c:531 +#13 0x0000555555c48fe5 in qemu_main_loop () at ../qemu-6.2.0/softmmu/runstate.c:726 +#14 0x000055555597b664 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../qemu-6.2.0/softmmu/main.c:50 +</code> +<br/> +It seems virtqueue_packed_pop() receives one desc with desc.len=65536 (or -1) which should not suppose to happen. I dont know why this is happening diff --git a/results/classifier/gemma3:12b/device/86 b/results/classifier/gemma3:12b/device/86 new file mode 100644 index 000000000..6982e049c --- /dev/null +++ b/results/classifier/gemma3:12b/device/86 @@ -0,0 +1,2 @@ + +powerpc 7450 MMU initialization broken diff --git a/results/classifier/gemma3:12b/device/869 b/results/classifier/gemma3:12b/device/869 new file mode 100644 index 000000000..76553dcf9 --- /dev/null +++ b/results/classifier/gemma3:12b/device/869 @@ -0,0 +1,22 @@ + +Qemu-system-avr working example +Description of problem: +I'm trying to get an Arduino board emulated with QEMU. Unfortunately, I can't get it to work. +I tried the commands, given in [https://qemu.readthedocs.io/en/latest/system/target-avr.html](https://qemu.readthedocs.io/en/latest/system/target-avr.html) and also downloaded and used the example elf file. + + +I then tried some more basic commands and used`qemu-system-avr -machine uno`. This should +run without any problems or? I also tried `2009` and `mega2560`. + +I also searched on the internet about working examples as well as further usage information, but I couldn't really find much. +Therefore, I hope someone can help me out or point me to additional material. +Steps to reproduce: +1. run `qemu-system-avr -machine uno` +2. wait around 5-10 seconds +3. on the terminal the following message appears with the qemu window crashing +``` +$ qemu-system-avr -machine uno + qemu-system-avr: execution left flash memory +``` +Additional information: +I'm fairly new to this, so please excuse me if I forgot something to post or made a mistake while posting. diff --git a/results/classifier/gemma3:12b/device/877498 b/results/classifier/gemma3:12b/device/877498 new file mode 100644 index 000000000..b4040d94b --- /dev/null +++ b/results/classifier/gemma3:12b/device/877498 @@ -0,0 +1,4 @@ + +qemu does not pass sector size from physical devices to virtual devices + +When passing a physical disk (i.e. a multipathed fcal volume in my case) with a 4k sector size as raw image to qemu (-drive file=/dev/mapper/hartebeest-sys,if=none,id=drive-virtio-disk0,boot=on,format=raw), the resulting virtual device has a sector size of 512b, rendering the partition table unusable! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/878 b/results/classifier/gemma3:12b/device/878 new file mode 100644 index 000000000..584d9f1f4 --- /dev/null +++ b/results/classifier/gemma3:12b/device/878 @@ -0,0 +1,43 @@ + +Can't bind PCI device behind a PCI bridge (No such device) +Description of problem: +Qemu fails to assign the device with : +``` +qemu-system-x86_64: -device vfio-pci,host=3b:00.0: vfio 0000:3b:00.0: error getting device from group 72: No such device +Verify all devices in group 72 are bound to vfio-<bus> or pci-stub and not already in use +``` + +Looking at strace, we can see that the device is behind a PCI bridge: +``` +lstat("/sys", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 +lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci/devices/0000:3b:00.0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 +readlink("/sys/bus/pci/devices/0000:3b:00.0", "../../../devices/pci0000:3a/0000"..., 4095) = 53 +lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 +readlink("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", "../../../../bus/pci", 4095) = 19 +lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +ioctl(14, VFIO_GROUP_GET_DEVICE_FD, 0x56267b3b1320) = -1 ENODEV (No such device) +``` + +The issue is that the PCI bridge `0000:3a:02.0`, is used by "pcieport" kernel driver and not "vfio-pci". +After manually unbinding the PCI bridge from it's driver and binding it to vfio-pci qemu successfully attaches it to the VM. + +I saw online that qemu is suposed to automaticly unbind devices from the host, make them available to the VM and restore them to their previous state once the VM is shutdown. +This is not happening here. +Steps to reproduce: +1. Have a PCI device behind a PCI bridge +2. Launch a VM with the PCI device attached +3. Observe similar error messages +Additional information: +After reading [kernel vfio doc](https://www.kernel.org/doc/html/latest/driver-api/vfio.html#vfio-usage-example), I can see that `ls -l /sys/bus/pci/devices/0000:3b:00.0/iommu_group/devices` was supposed to list the PCI bridge, but it is not the case for me. + +I could only notice the presence of the bridge by looking in the `/sys/bus/pci/devices/0000:3b:00.0` symlink. + +Maybe qemu misses it because of that ? diff --git a/results/classifier/gemma3:12b/device/884 b/results/classifier/gemma3:12b/device/884 new file mode 100644 index 000000000..122c11e56 --- /dev/null +++ b/results/classifier/gemma3:12b/device/884 @@ -0,0 +1,9 @@ + +Stuck when using virtio driver to rotate the screen +Description of problem: +Configure the virtual machine's graphics card as Virtio, and use `xrandr -o left` to rotate the screen and it will get stuck. + +Configure the graphics card as VGA, and use `xrandr -o left` to rotate the screen normally. +Steps to reproduce: +1. Configure the virtual machine's graphics card as Virtio +2. use `xrandr -o left` to rotate the screen diff --git a/results/classifier/gemma3:12b/device/884401 b/results/classifier/gemma3:12b/device/884401 new file mode 100644 index 000000000..153b6f46e --- /dev/null +++ b/results/classifier/gemma3:12b/device/884401 @@ -0,0 +1,56 @@ + +PCI Passthrough for Digium TCE400P Codec Card Not working + +trying to use a Digium TCE400P Codec card on a Virtual instance using the following information: + +lspci <enter> + +02:08.0 Ethernet controller: Digium, Inc. Wildcard TCE400P transcoder base card (rev 11) + +lspci -n <enter> + +02:08.0 0200: d161:8004 (rev 11) + +virsh nodedev-list | grep pci + +pci_0000_02_08_0 + +printf %x 02 +2 + +printf %x 08 +8 + +printf %x 0 +0 + +bus='0x02' +slot='0x08' +function='0x0' + +# virsh edit vmanager +<hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0x02' slot='0x08' function='0x0'/> + </source> +</hostdev> + +I have SELINUX disabled at this time. + +virsh start vmanager I get the following error message: + +[root@twins qemu]# virsh start vmanager +error: Failed to start domain vmanager +error: internal error Process exited while reading console log output: char device redirected to /dev/pts/2 +Unable to assign device: PCI region 1 at address 0xdf1fe000 has size 0x400, which is not a multiple of 4K +qemu-kvm: -device pci-assign,host=02:08.0,id=hostdev0,configfd=23,bus=pci.0,addr=0x6: Device 'pci-assign' could not be initialized + + + +Version Numbers: + +[root@twins qemu]# yum list | grep qemu +gpxe-roms-qemu.noarch 0.9.7-6.3.el6_0.1 @updates +qemu-img.x86_64 2:0.12.1.2-2.113.el6_0.8 @updates +qemu-kvm.x86_64 2:0.12.1.2-2.113.el6_0.8 @updates +qemu-kvm-tools.x86_64 2:0.12.1.2-2.113.el6_0.8 updates \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/89 b/results/classifier/gemma3:12b/device/89 new file mode 100644 index 000000000..6d777f423 --- /dev/null +++ b/results/classifier/gemma3:12b/device/89 @@ -0,0 +1,2 @@ + +Documentation for mtdblock, option-rom, and pflash is non-existent diff --git a/results/classifier/gemma3:12b/device/893367 b/results/classifier/gemma3:12b/device/893367 new file mode 100644 index 000000000..945822d56 --- /dev/null +++ b/results/classifier/gemma3:12b/device/893367 @@ -0,0 +1,11 @@ + +HPET supports only one IRQ + +The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CPUs and each timer block can be driven by a different IRQ. + +TIMER: HPET at fed00000 -> 0xbf500000. +TIMER: HPET vendor 8086 revision 01: LEGACY 64BIT +TIMER: HPET: cap 8086a201 config 0 period 10000000 +TIMER: HPET Timer[0]: config 30 int 4 +TIMER: HPET Timer[1]: config 30 int 4 +TIMER: HPET Timer[2]: config 30 int 4 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/897466 b/results/classifier/gemma3:12b/device/897466 new file mode 100644 index 000000000..e15e03043 --- /dev/null +++ b/results/classifier/gemma3:12b/device/897466 @@ -0,0 +1,22 @@ + +UHCI Host Controller no longer present with -usb + +If on an up to date 12.04 install and I start a VM with: +$ qemu -m 192 -serial none -chardev null,id=chardevmon -pidfile /tmp/pid -daemonize -nographic -monitor tcp:127.0.0.1:4444,server,nowait -net user,hostfwd=tcp:127.0.0.1:4422-:22 -usb -rtc base=utc -name qatest-vm -uuid ded3a46b-bb60-43f4-8113-d041aeb93cdf -hda libvirt/qatest/qatest.qcow2 + +Then use the 'info usbhost' in the monitor, I get: +$ echo 'info usbhost' | nc -q 1 127.0.0.1 4444 +(qemu) info usbhost +husb: using sys file-system with /dev/bus/usb +$ + +In Oneiric and eariler, 'info usbhost' would should a UHCI Host Controller. Eg: +$ qemu -m 192 -serial none -chardev null,id=chardevmon -pidfile /tmp/pid -daemonize -nographic -monitor tcp:127.0.0.1:4444,server,nowait -net user,hostfwd=tcp:127.0.0.1:4422-:22 -usb -rtc base=utc -name qatest-vm -uuid ded3a46b-bb60-43f4-8113-d041aeb93cdf -hda libvirt/qatest/qatest.qcow2 +echo 'info usbhost' | nc -q 1 127.0.0.1 4444 +QEMU 0.14.1 monitor - type 'help' for more information +(qemu) info usbhost +husb: using sys file-system with /dev/bus/usb + Device 1.1, speed 12 Mb/s + Hub: USB device 1d6b:0001, UHCI Host Controller + +This breaks QRT/scripts/test-qemu.py and appears to be a regression, but I am not sure if it is a 3.2 kernel issue or a 0.14.1 vs 0.15 issue. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/906221 b/results/classifier/gemma3:12b/device/906221 new file mode 100644 index 000000000..94c676a37 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/906864 b/results/classifier/gemma3:12b/device/906864 new file mode 100644 index 000000000..487b2aa57 --- /dev/null +++ b/results/classifier/gemma3:12b/device/906864 @@ -0,0 +1,16 @@ + +Always mouse grabbing with -usbdevice tablet + +version: QEMU emulator version 1.0 (qemu-kvm 1.0) + QEMU emulator version 1.0 (qemu 1.0) + (source builds) +os: archlinux x86-64 +last working version: qemu-kvm 0.15.1 + +commandline: each with "-usb -usbdevice tablet" and sdl output + +expected behavior: mouse gets grabbed only by forcing it (pressing release/grab-combination (CTRL-ALT)) + +actual behavior: +When moving the mouse over the window it gets instantly grabbed, so i cannot use window-manager-specific hotkeys anymore. After pressing the release combination every mouse movement over or within the window will grab the mouse again. +I have tried this with several vga types and window managers: no difference \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/91 b/results/classifier/gemma3:12b/device/91 new file mode 100644 index 000000000..2bf8be882 --- /dev/null +++ b/results/classifier/gemma3:12b/device/91 @@ -0,0 +1,2 @@ + +RFE: Implement support for SMBIOS Type 41 structures diff --git a/results/classifier/gemma3:12b/device/917 b/results/classifier/gemma3:12b/device/917 new file mode 100644 index 000000000..d04e28010 --- /dev/null +++ b/results/classifier/gemma3:12b/device/917 @@ -0,0 +1,2 @@ + +FireWire Device Passthrough? diff --git a/results/classifier/gemma3:12b/device/92 b/results/classifier/gemma3:12b/device/92 new file mode 100644 index 000000000..c1a27a550 --- /dev/null +++ b/results/classifier/gemma3:12b/device/92 @@ -0,0 +1,2 @@ + +qemu 1.3.0: usb devices shouldn't have same vendor/product ID and same serial diff --git a/results/classifier/gemma3:12b/device/920772 b/results/classifier/gemma3:12b/device/920772 new file mode 100644 index 000000000..54fff66f7 --- /dev/null +++ b/results/classifier/gemma3:12b/device/920772 @@ -0,0 +1,38 @@ + +Win98SE glitches RHEL6.2/CentOS6.2 QEMU + +I'm not sure if this is something anyone will be interested in, +but I ran into some glitches setting up a Windows 98 SE +QEMU VM with a relatively recent version. Needed this +to restore an ancient backup and got it working well +enough to get the job done. + +Versions +======== + +Distro: CentOS 6.2 + +Kernel: upstream 3.1.8 + +QEMU: +gpxe-roms-qemu-0.9.7-6.9.el6.noarch +qemu-img-0.12.1.2-2.209.el6_2.1.x86_64 +qemu-kvm-0.12.1.2-2.209.el6_2.1.x86_64 + +Glitches: + +1) Doesn't work in KVM mode, screen goes black +just after installer is finishing up and switching to +Win98. Saw this issue has been around for awhile. + +2) Got it working in QEMU mode, but BIOS plug-n-play +driver fails. This prevents other devices from working. + +a) CDROM not recognized + +b) Realtek 8139C driver (installed separately after +Win98) not recognized. + +I don't need these issues fixed, just reporting the +in case it's of interest and/or helpful. Can provide +more detail on request. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/924 b/results/classifier/gemma3:12b/device/924 new file mode 100644 index 000000000..53933f305 --- /dev/null +++ b/results/classifier/gemma3:12b/device/924 @@ -0,0 +1,2 @@ + +AHCI IRQ lost running Fedora on SBSA-ref diff --git a/results/classifier/gemma3:12b/device/933 b/results/classifier/gemma3:12b/device/933 new file mode 100644 index 000000000..76042956f --- /dev/null +++ b/results/classifier/gemma3:12b/device/933 @@ -0,0 +1,27 @@ + +Changing CD ROM medium sometimes fails with 'Tray of device is not open' +Description of problem: +QEMU reports that a CD ROM tray is not open when exchanging media: +`unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'ide0-1-0' is not open` + +We see the issue in upstream libvirt integration tests. However, this issue is a race and the reproducibility rate is <15%. +Steps to reproduce: +On the high level this is what we do: +1. eject medium that the machine was started with +2. insert a different medium into the CD ROM + +Translating the above to QEMU QMP commands this is what the test exercises: +1. blockdev-open-tray +2. blockdev-remove-medium +3. blockdev-del +4. blockdev-close-tray +5. blockdev-open-tray +6. blockdev-remove-medium +7. blockdev-add +8. blockdev-insert-medium <<< This is where the test fails +9. blockdev-close-tray +Additional information: +I bisected the code (3 times just to be sure since it's a race) and the following commit fell out of it: +55adb3c45620c31f29978f209e2a44a08d34e2da + +I'm attaching QEMU trace events and a bunch of libvirt test logs (good and bad for comparison). If you think of anything else I should provide in order to help with the issue analysis, please let me know what other option should be turned on.[qemu_traces.tar.gz](/uploads/32e48c92efce3484e552df063795af4d/qemu_traces.tar.gz) diff --git a/results/classifier/gemma3:12b/device/935 b/results/classifier/gemma3:12b/device/935 new file mode 100644 index 000000000..460b4072f --- /dev/null +++ b/results/classifier/gemma3:12b/device/935 @@ -0,0 +1,60 @@ + +insert ivshmem device into pci-bridge, but vm network disconnects +Description of problem: +To extend PCI slot number in Windows vm, a new pci-bridge is created in Windows vm as bus.1. But when I insert a ivshmem file in host to this pci-bridge(bus.1), the Windows vm disconnects(lose remote desktop connection). +Steps to reproduce: +1. add new pci-bridge into windows vm, add windows vm xml configuration like this: +```xml +<devices> + <controller type='pci' index='0' model='pci-root'/> + <controller type='pci' index='1' model='pci-bridge'> + <address type='pci' domain='0' bus='0' slot='0x0d' function='0' multifunction='off'/> + </controller> +</devices> +``` + +2.restart this Windows vm, new pci-bridge has been created, its name is pci.1 and bus is bus.1: +```sh +$ virsh qemu-monitor-command --hmp --domain 56 --cmd info pci + Bus 0, device 13, function 0: + PCI bridge: PCI device 1b36:0001 + IRQ 10. + BUS 0. + secondary bus 1. + subordinate bus 1. + IO range [0xc000, 0xcfff] + memory range [0xfe000000, 0xfe1fffff] + prefetchable memory range [0xe4000000, 0xe41fffff] + BAR0: 64 bit memory at 0xfe422000 [0xfe4220ff]. + id "pci.1" +``` +3. create a shm file `/dev/shm/test1` in host using `shm_open()`, size is 32M + +4. create new object: +```sh +virsh qemu-monitor-command --hmp --domain 56 --cmd object_add memory-backend-file,share=on,id=objtest1,size=32M,mem-path=/dev/shm/test1 +``` + +5. insert this ivshmem file into new pci-bridge and use bus.1 slot number(1:1.0): +```sh +virsh qemu-monitor-command --hmp --domain 56 --cmd device_add ivshmem-plain,memdev=objtest1,id=test1,bus=pci.1,addr=0x01.0x00 +``` + +6. After inserting this ivshmem file into new pci-bridge, the remote desktop connection of this windows vm disconnects. + +7. New ivshmem file has been created: +``` +$ virsh qemu-monitor-command --hmp --domain 57 --cmd info pci + Bus 1, device 1, function 0: + RAM controller: PCI device 1af4:1110 + BAR0: 32 bit memory at 0xfe1fff00 [0xfe1fffff]. + BAR2: 64 bit prefetchable memory at 0x4bc000000 [0x4bfffffff]. + id "test1" + +``` +Additional information: +When insert ivshmem file into bus.1(pci-bridge), the remote desktop connection of Windows vm is sometimes disconnected, and sometimes it is normal. + +The newly added ivshmem device can be found in the device manager of the Windows vm, but sometimes it cannot be found. + +Thanks for your help! diff --git a/results/classifier/gemma3:12b/device/940 b/results/classifier/gemma3:12b/device/940 new file mode 100644 index 000000000..bdf7122dd --- /dev/null +++ b/results/classifier/gemma3:12b/device/940 @@ -0,0 +1,2 @@ + +"analyze-migration.py -m" does not appear to account for the pci-hole diff --git a/results/classifier/gemma3:12b/device/942 b/results/classifier/gemma3:12b/device/942 new file mode 100644 index 000000000..145cbaa06 --- /dev/null +++ b/results/classifier/gemma3:12b/device/942 @@ -0,0 +1,2 @@ + +No TPM support for riscv64 in QEMU diff --git a/results/classifier/gemma3:12b/device/946043 b/results/classifier/gemma3:12b/device/946043 new file mode 100644 index 000000000..42568d4e2 --- /dev/null +++ b/results/classifier/gemma3:12b/device/946043 @@ -0,0 +1,13 @@ + +Serial Named Pipe Unrecognized Windows 7 + +I created a named pipe serial hardware and supplied '/tmp/debug' which I created using mkfifo + +This is the snippet from ps -aux +-chardev pipe,id=charserial0,path=/tmp/debug -device isa-serial,chardev=charserial0,id=serial0 + +failure@ubuntu1:~$ ls -al /tmp/debug* +prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug +prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug.in + +However inside the Windows 7 guest (even after a restart) nothing is recognized. Even after going through the add legacy hardware motions it's still not picked up. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/951 b/results/classifier/gemma3:12b/device/951 new file mode 100644 index 000000000..121a5d7a0 --- /dev/null +++ b/results/classifier/gemma3:12b/device/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/gemma3:12b/device/959852 b/results/classifier/gemma3:12b/device/959852 new file mode 100644 index 000000000..1090ba691 --- /dev/null +++ b/results/classifier/gemma3:12b/device/959852 @@ -0,0 +1,30 @@ + +Build fails: osx 10.7, deprecated CoreAudio APIs + +Virtual audio driver for darwin is using deprecated APIs. + +○ → ./configure --cc=/usr/bin/gcc --disable-darwin-user --disable-bsd-user --disable-guest-agent + + +○ → make +. +. +. + CC audio/noaudio.o + CC audio/wavaudio.o + CC audio/mixeng.o + CC audio/coreaudio.o +audio/coreaudio.c: In function ‘isPlaying’: +audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c: In function ‘coreaudio_init_out’: +audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270) +audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) +audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) +audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419) +audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) +audio/coreaudio.c: In function ‘coreaudio_fini_out’: +audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) + CC audio/wavcapture.o \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/965 b/results/classifier/gemma3:12b/device/965 new file mode 100644 index 000000000..3b89ff4c6 --- /dev/null +++ b/results/classifier/gemma3:12b/device/965 @@ -0,0 +1,2 @@ + +Creating a NVME disk using qemu in the Host not in the VM diff --git a/results/classifier/gemma3:12b/device/972 b/results/classifier/gemma3:12b/device/972 new file mode 100644 index 000000000..6563d09ae --- /dev/null +++ b/results/classifier/gemma3:12b/device/972 @@ -0,0 +1,2 @@ + +LSI SCSI Use After Free (CVE-2022-0216) diff --git a/results/classifier/gemma3:12b/device/978 b/results/classifier/gemma3:12b/device/978 new file mode 100644 index 000000000..e0803182e --- /dev/null +++ b/results/classifier/gemma3:12b/device/978 @@ -0,0 +1,2 @@ + +Running QEMU with "-vga help" crashes if there is no default VGA card diff --git a/results/classifier/gemma3:12b/device/984476 b/results/classifier/gemma3:12b/device/984476 new file mode 100644 index 000000000..474242f5a --- /dev/null +++ b/results/classifier/gemma3:12b/device/984476 @@ -0,0 +1,6 @@ + +"segmentaion" error when DMAing + +When working with QEMU's PCI network card E1000 emulator, I accidentally put virtual addresses into the memory mapped registers when I should have put physical addresses. Short story is, the address was too large for the physical address space so when the network card tried to DMA the location it tossed a "segmentaion" error out to the console. That's right--not a "segmentation" error, but a "segmentaion" error. I just thought I'd let ya'll know about that little typo. + +My "qemu -version" gives "QEMU emulator version 0.15.0, Copyright (c) 2003-2008 Fabrice Bellard" on linux version 2.6.32. I guess it might be an older version, dunno if the typo's still there. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/985288 b/results/classifier/gemma3:12b/device/985288 new file mode 100644 index 000000000..fb599cc19 --- /dev/null +++ b/results/classifier/gemma3:12b/device/985288 @@ -0,0 +1,4 @@ + +scsi disk emulation doesn't enforce FUA (Force Unit Access) in write-back mode + +Microsoft NTFS utilizes the FUA bit in SCSI WRITE CDBs to insure integrity when a device advertises that it has write caching enabled. The FUA bit is meant to ensure a write is written to non-volatile storage before returning. This seems to not be enforced by QEMU's SCSI emulation code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/986770 b/results/classifier/gemma3:12b/device/986770 new file mode 100644 index 000000000..8ea5bdd61 --- /dev/null +++ b/results/classifier/gemma3:12b/device/986770 @@ -0,0 +1,7 @@ + +Oops: spice configured but not active + +with latest qemu-kvm from git i have following problem: + + /usr/bin/kvm -daemonize -smp 4 -cpu host -vga qxl -enable-kvm -m 4096 -localtime -drive file=/home/sss/vm/win_xp/tmp_sys.img,if=virtio,media=disk,cache=none -drive file=/home/sss/vm/data.img,if=virtio,media=disk,cache=none -net nic,vlan=0,model=virtio,macaddr=6a:94:fc:2d:b9:04 -net tap,vlan=0,ifname=vtap0,script=no -usb -usbdevice tablet -name "Windows XP qt" -spice port=5934,addr=127.0.0.1,ipv4,playback-compression=off,disable-ticketing -monitor telnet::4448,server,nowait -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -balloon virtio +qemu-system-x86_64: Oops: spice configured but not active \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/989504 b/results/classifier/gemma3:12b/device/989504 new file mode 100644 index 000000000..abe0d2885 --- /dev/null +++ b/results/classifier/gemma3:12b/device/989504 @@ -0,0 +1,24 @@ + +assertion failed when attaching USB MSD device + +version: git rev be5ea8ed4481f0ffa4ea0f7ba13e465701536001 +commandline: qemu-system-i386 -usb -fda dosusb.img -drive if=none,id=usbstick,file=usb.img -device usb-storage,bus=usb.0,drive=usbstick -boot a -L d:\_programs\qemu + +--------------------------- +Microsoft Visual C++ Runtime Library +--------------------------- +Assertion failed! + +Program: E:\qemu-system-i386.exe +File: C:/msys/home/User/qemu/hw/usb/hcd-uhci.c +Line: 968 + +Expression: ret == TD_RESULT_ASYNC_START + +For information on how your program can cause an assertion +failure, see the Visual C++ documentation on asserts + +(Press Retry to debug the application - JIT must be enabled) +--------------------------- +Abort Retry Ignore +--------------------------- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/device/99 b/results/classifier/gemma3:12b/device/99 new file mode 100644 index 000000000..714fdae56 --- /dev/null +++ b/results/classifier/gemma3:12b/device/99 @@ -0,0 +1,2 @@ + +Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation diff --git a/results/classifier/gemma3:12b/device/990364 b/results/classifier/gemma3:12b/device/990364 new file mode 100644 index 000000000..9792fe36c --- /dev/null +++ b/results/classifier/gemma3:12b/device/990364 @@ -0,0 +1,19 @@ + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +Hello! I have: + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +on config: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" + +with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +qemu drivers are virtio-win-0.1-22.iso +kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +qemu 0.12.3+noroms-0ubuntu9.18 \ No newline at end of file |