diff options
Diffstat (limited to 'results/classifier/118/x86')
95 files changed, 5171 insertions, 0 deletions
diff --git a/results/classifier/118/x86/1033494 b/results/classifier/118/x86/1033494 new file mode 100644 index 000000000..f19190d44 --- /dev/null +++ b/results/classifier/118/x86/1033494 @@ -0,0 +1,45 @@ +x86: 0.879 +kernel: 0.788 +graphic: 0.738 +mistranslation: 0.669 +device: 0.668 +KVM: 0.557 +user-level: 0.551 +hypervisor: 0.544 +architecture: 0.533 +network: 0.466 +ppc: 0.451 +virtual: 0.432 +performance: 0.422 +i386: 0.396 +socket: 0.395 +boot: 0.341 +semantic: 0.330 +debug: 0.297 +vnc: 0.292 +register: 0.285 +files: 0.245 +risc-v: 0.239 +PID: 0.236 +permissions: 0.230 +peripherals: 0.206 +arm: 0.193 +VMM: 0.151 +TCG: 0.133 +assembly: 0.099 + +qemu-system-x86_64 segfaults with kernel 3.5.0 + +qemu-kvm 1.1.1 stable is running fine for me with RHEL 6 2.6.32 based kernel. + +But with 3.5.0 kernel qemu-system-x86_64 segfaults while i'm trying to install ubuntu 12.04 server reproducable. + +You find three backtraces here: +http://pastebin.com/raw.php?i=xCy2pEcP + +Stefan + +this thread and this fix http://thread.gmane.org/gmane.comp.emulators.kvm.devel/95314/focus=1338226 are about the same issue, apparently. Please try it and see if it fixes you issue too. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1091 b/results/classifier/118/x86/1091 new file mode 100644 index 000000000..642b60cc3 --- /dev/null +++ b/results/classifier/118/x86/1091 @@ -0,0 +1,43 @@ +x86: 0.989 +device: 0.883 +kernel: 0.844 +graphic: 0.824 +architecture: 0.705 +performance: 0.652 +mistranslation: 0.410 +vnc: 0.407 +debug: 0.397 +semantic: 0.354 +PID: 0.334 +boot: 0.271 +TCG: 0.263 +virtual: 0.237 +hypervisor: 0.233 +peripherals: 0.232 +register: 0.209 +VMM: 0.208 +permissions: 0.201 +ppc: 0.198 +KVM: 0.187 +network: 0.181 +user-level: 0.169 +files: 0.158 +risc-v: 0.134 +socket: 0.122 +arm: 0.104 +assembly: 0.017 +i386: 0.014 + +qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac +Description of problem: +The QEMU process hard crashes after a few minutes. The only message is: + +``` +vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed +``` +Steps to reproduce: +1. Run QEMU with the above commandline +2. Do something to keep the VM busy - running `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` reliably crashes it for me +3. Wait a 3-5 minutes +Additional information: + diff --git a/results/classifier/118/x86/1095857 b/results/classifier/118/x86/1095857 new file mode 100644 index 000000000..aa39c2f5f --- /dev/null +++ b/results/classifier/118/x86/1095857 @@ -0,0 +1,46 @@ +x86: 0.883 +architecture: 0.796 +register: 0.772 +mistranslation: 0.764 +graphic: 0.736 +device: 0.679 +user-level: 0.641 +performance: 0.570 +semantic: 0.442 +debug: 0.408 +kernel: 0.402 +network: 0.323 +assembly: 0.286 +socket: 0.242 +arm: 0.222 +boot: 0.214 +vnc: 0.198 +i386: 0.172 +virtual: 0.170 +permissions: 0.167 +ppc: 0.167 +hypervisor: 0.163 +PID: 0.156 +files: 0.154 +VMM: 0.124 +KVM: 0.114 +risc-v: 0.096 +peripherals: 0.086 +TCG: 0.077 + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +end up executing as + +mov eax,[r15] + +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. + +You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1185888 b/results/classifier/118/x86/1185888 new file mode 100644 index 000000000..57df9ddc3 --- /dev/null +++ b/results/classifier/118/x86/1185888 @@ -0,0 +1,60 @@ +x86: 0.894 +virtual: 0.817 +graphic: 0.753 +device: 0.745 +architecture: 0.731 +ppc: 0.724 +socket: 0.662 +mistranslation: 0.647 +vnc: 0.642 +semantic: 0.606 +user-level: 0.581 +VMM: 0.540 +network: 0.465 +risc-v: 0.459 +PID: 0.450 +register: 0.432 +arm: 0.421 +boot: 0.416 +debug: 0.405 +hypervisor: 0.393 +performance: 0.373 +peripherals: 0.358 +kernel: 0.338 +permissions: 0.335 +TCG: 0.316 +KVM: 0.289 +i386: 0.276 +files: 0.260 +assembly: 0.162 + +-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). + +Snapshotting for XHCI has been implemented after QEMU 1.5.0: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=37352df30fbc38d1de464db8 +... i.e. this should be working since QEMU 1.6.0. So I'm setting the status to "Fix Released" - if you still have problems with the latest version of QEMU, please feel free to open this ticket again. + diff --git a/results/classifier/118/x86/1192344 b/results/classifier/118/x86/1192344 new file mode 100644 index 000000000..1b4bf3d26 --- /dev/null +++ b/results/classifier/118/x86/1192344 @@ -0,0 +1,56 @@ +x86: 0.860 +graphic: 0.818 +register: 0.746 +performance: 0.697 +device: 0.684 +architecture: 0.615 +ppc: 0.600 +socket: 0.580 +PID: 0.531 +files: 0.522 +network: 0.517 +semantic: 0.515 +boot: 0.513 +vnc: 0.501 +mistranslation: 0.472 +risc-v: 0.461 +kernel: 0.449 +user-level: 0.436 +TCG: 0.419 +arm: 0.409 +VMM: 0.400 +hypervisor: 0.382 +debug: 0.360 +permissions: 0.358 +virtual: 0.316 +peripherals: 0.289 +i386: 0.285 +KVM: 0.190 +assembly: 0.099 + +qemu crashes on unaligned extended disk reads + +When performing a BIOS extended disk read (INT 13H, AH=0x42), if the offset of the buffer destination in the DAP (disk address packet) is not dword-aligned (i.e. a multiple of 4), SeaBIOS attempts to execute code at non-mapped address 0xb4f53, causing QEMU to crash. I imagine it's a bug in the BIOS code, but it does cause QEMU to crash. + +QEMU version: 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) (from Ubuntu repository) +SeaBIOS version: 1.7.2-20130119_170942-roseapple +command line: qemu-system-x86_64 -m 64 -hda hda.img -monitor stdio +CPU: Intel Core i7 CPU M620 on a Dell Latitude E6410 +OS: Ubuntu, GNU/Linux 3.8.0-25-generic, 64-bit + +On Tue, Jun 18, 2013 at 09:23:31PM -0000, Andrew McGowen wrote: +> When performing a BIOS extended disk read (INT 13H, AH=0x42), if the +> offset of the buffer destination in the DAP (disk address packet) is not +> dword-aligned (i.e. a multiple of 4), SeaBIOS attempts to execute code +> at non-mapped address 0xb4f53, causing QEMU to crash. I imagine it's a +> bug in the BIOS code, but it does cause QEMU to crash. + +Can you post details on the "crash"? What is the error message? + +Stefan + + +...well this is embarrassing - it was an issue with my code not saving/restoring registers on the stack properly. + +Marking this ticket as "Invalid" according to comment #2. + diff --git a/results/classifier/118/x86/1196773 b/results/classifier/118/x86/1196773 new file mode 100644 index 000000000..d19de0a5a --- /dev/null +++ b/results/classifier/118/x86/1196773 @@ -0,0 +1,44 @@ +x86: 0.856 +graphic: 0.807 +mistranslation: 0.572 +boot: 0.490 +ppc: 0.487 +peripherals: 0.472 +architecture: 0.466 +network: 0.436 +performance: 0.425 +vnc: 0.366 +semantic: 0.332 +device: 0.271 +i386: 0.248 +debug: 0.231 +socket: 0.224 +user-level: 0.213 +PID: 0.210 +virtual: 0.166 +register: 0.138 +permissions: 0.124 +VMM: 0.112 +hypervisor: 0.090 +arm: 0.052 +risc-v: 0.048 +TCG: 0.044 +assembly: 0.039 +files: 0.031 +kernel: 0.023 +KVM: 0.018 + +pci_add auto nic failed on qemu monitor + +hello! +execute "qemu-system-x86_64 -M pc -m 256 -hda pc/img.qcow2 -nographic -net nic,vlan=0,macaddr=00:e0:fc:00:00:01 -net tap,vlan=0,ifname=tap0,script=no -serial tcp::3333,server,nowait -boot c" +and then +(qemu) pci_add auto nic vlan=1,macaddr=00:e0:fc:40:20:02 +Property 'e1000.netdev' can't take value 'hub0port0', it's in use + +the qemu version is 1.4.1 + +thx! + +The pci_add command has been remove since QEMU 2.3.0 ... so I'm closing this bug now - sorry that nobody picked this up in 2013! If you still can reproduce this problem with device_add, please feel free to open this ticket again. + diff --git a/results/classifier/118/x86/1251470 b/results/classifier/118/x86/1251470 new file mode 100644 index 000000000..33899a8c1 --- /dev/null +++ b/results/classifier/118/x86/1251470 @@ -0,0 +1,59 @@ +x86: 0.810 +device: 0.723 +debug: 0.545 +graphic: 0.489 +boot: 0.465 +KVM: 0.433 +performance: 0.399 +semantic: 0.357 +architecture: 0.335 +mistranslation: 0.318 +hypervisor: 0.312 +virtual: 0.312 +TCG: 0.277 +ppc: 0.273 +user-level: 0.272 +register: 0.267 +files: 0.261 +socket: 0.219 +kernel: 0.197 +PID: 0.191 +permissions: 0.191 +network: 0.186 +arm: 0.156 +vnc: 0.152 +risc-v: 0.134 +peripherals: 0.085 +assembly: 0.069 +VMM: 0.067 +i386: 0.044 + +Guest not working in KVM mode but does in TCG mode + +Qemu: 1.5.0 (Debian 1.5.0+dfsg-3ubuntu5) +Host: Ubuntu 13.10 x86_64 (Intel Core i7-950) +Guest: FreeBSD 9.2 RELEASE x86_64 + +As initially reported here: https://www.redhat.com/archives/libvirt-users/2013-November/msg00066.html +I was told that this is a bug in Qemu. + +Basically this command works: +qemu-system-x86_64 -hda images/FreeBSD-9.2-RELEASE-amd64.img + +But this one doesn't: +qemu-system-x86_64 -machine accel=kvm -hda images/FreeBSD-9.2-RELEASE-amd64.img + +FreeBSD is stuck after the bootloader: +Booting... +CPU doesn't support long mode + +Same behaviour with git master (5c5432e7d630592ddcc1876ac8a1505f8f14ef15) + +I'll download FreeBSD 9.2 and debug it. In the meanwhile, does it work with an additional option "-cpu Nehalem"? + +For what it's worth, with 1.7.0+dfsg-3ubuntu6 and using the image FreeBSD-9.2-RELEASE-amd64-bootonly.iso kvm is working for me. + +saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix". + +According to comment #3, this bug has been fixed, so I'm closing this ticket now. If you can still reproduce this issue with the latest version from QEMU, please feel free to open this ticket again. + diff --git a/results/classifier/118/x86/1292037 b/results/classifier/118/x86/1292037 new file mode 100644 index 000000000..3be12c6a1 --- /dev/null +++ b/results/classifier/118/x86/1292037 @@ -0,0 +1,49 @@ +x86: 0.986 +i386: 0.973 +graphic: 0.824 +device: 0.772 +architecture: 0.706 +performance: 0.583 +network: 0.467 +PID: 0.451 +semantic: 0.419 +mistranslation: 0.373 +files: 0.373 +ppc: 0.348 +vnc: 0.335 +register: 0.311 +socket: 0.273 +peripherals: 0.266 +VMM: 0.261 +user-level: 0.202 +risc-v: 0.196 +TCG: 0.186 +debug: 0.185 +boot: 0.166 +permissions: 0.161 +hypervisor: 0.159 +kernel: 0.137 +virtual: 0.122 +arm: 0.112 +assembly: 0.039 +KVM: 0.005 + +Solaris 10 x86 guest crashes qemu with -icount 1 option + +Commit: f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git + +Solaris image: Solaris 10 x86 (32 bit) + +command: ./i386-softmmu/qemu-system-i386 -hda <image-file> -m 2G -icount 1 -monitor stdio + +Crashes saying: +qemu: Fatal: Raised interrupt while not in I/O function + +Host: +ubuntu x86_64 3.2.0-56 generic +intel xeon E5649 @ 2.53GHz + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1309034 b/results/classifier/118/x86/1309034 new file mode 100644 index 000000000..871fde868 --- /dev/null +++ b/results/classifier/118/x86/1309034 @@ -0,0 +1,65 @@ +x86: 0.847 +KVM: 0.812 +graphic: 0.788 +peripherals: 0.775 +device: 0.757 +semantic: 0.722 +architecture: 0.692 +boot: 0.677 +ppc: 0.665 +mistranslation: 0.662 +PID: 0.651 +permissions: 0.631 +socket: 0.617 +kernel: 0.615 +user-level: 0.604 +files: 0.569 +debug: 0.557 +arm: 0.556 +register: 0.548 +network: 0.548 +risc-v: 0.531 +assembly: 0.527 +performance: 0.499 +vnc: 0.487 +VMM: 0.478 +hypervisor: 0.437 +virtual: 0.414 +TCG: 0.340 +i386: 0.217 + +A way not to grab keyboards or mice + +I set up the window manager to move windows with Alt-Btn1, and to +iconify windows with Shift-Btn1. But since qemu grabs keyboards and +mice, I can't move or iconify the qemu window. + +I tried not to grab anything, by inserting return, just beginnig of +ui/sdl.c:sdl_grab_start() as follows: + +static void sdl_grab_start(void) +{ + return; + /* + +It is comfortable. I'm glad if you make a way not to grab. +Environment variables, options, etc are welcome. + +Current command line is: +QEMU_AUDIO_DRV=pa /usr/local/bin/qemu-system-x86_64 -enable-kvm -hda /dosc/win8_x64.img -soundhw hda -boot c -m 2G -cpu Nehalem,+sep -usb -usbdevice tablet -display sdl -rtc base=localtime + +qemu version is: +luna:linux % qemu-system-x86_64 --version +QEMU emulator version 1.7.93, Copyright (c) 2003-2008 Fabrice Bellard +luna:linux % + +Host: slackware64 14.1 +Host Environment: xfce4 / sawfish +Guest: Windows 8.1 x64 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1323 b/results/classifier/118/x86/1323 new file mode 100644 index 000000000..61a5ddb7f --- /dev/null +++ b/results/classifier/118/x86/1323 @@ -0,0 +1,47 @@ +x86: 0.949 +graphic: 0.894 +device: 0.873 +architecture: 0.770 +boot: 0.660 +semantic: 0.471 +PID: 0.464 +socket: 0.374 +register: 0.358 +mistranslation: 0.356 +files: 0.329 +permissions: 0.318 +ppc: 0.300 +performance: 0.290 +network: 0.281 +vnc: 0.260 +user-level: 0.257 +peripherals: 0.238 +debug: 0.231 +i386: 0.194 +assembly: 0.192 +risc-v: 0.158 +arm: 0.155 +VMM: 0.149 +TCG: 0.146 +kernel: 0.099 +virtual: 0.054 +hypervisor: 0.049 +KVM: 0.022 + +qemu-system-x86_64: keyboard not available in cd boot menu +Description of problem: +While CD boot menu is shown, no keys input affects the CD boot menu +Steps to reproduce: +1. Execute qemu-system-x86_64 -m 1536 -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +2. Wait for boot menu +3. Try to choose entry +Additional information: +Also occurs with other ISOs + + ``` + qemu-system-x86_64 -m 1536 -cdrom debian-10.8.0-amd64-netinst.iso + ``` + +Does not occur with provided edk2 firmware + +Does not occur with QEMU emulator version 7.1.0 diff --git a/results/classifier/118/x86/1358722 b/results/classifier/118/x86/1358722 new file mode 100644 index 000000000..9e96a431d --- /dev/null +++ b/results/classifier/118/x86/1358722 @@ -0,0 +1,52 @@ +x86: 0.921 +device: 0.825 +boot: 0.799 +architecture: 0.792 +i386: 0.767 +ppc: 0.718 +graphic: 0.693 +KVM: 0.628 +semantic: 0.623 +files: 0.591 +PID: 0.580 +vnc: 0.574 +performance: 0.527 +mistranslation: 0.522 +register: 0.493 +kernel: 0.490 +socket: 0.476 +virtual: 0.469 +debug: 0.411 +user-level: 0.401 +network: 0.378 +risc-v: 0.316 +arm: 0.315 +TCG: 0.293 +permissions: 0.281 +assembly: 0.266 +VMM: 0.262 +peripherals: 0.238 +hypervisor: 0.091 + +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. + +The experiments for running MacOSXon KVM/QEMU I followed are here: http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1387 b/results/classifier/118/x86/1387 new file mode 100644 index 000000000..d3ce5b5c6 --- /dev/null +++ b/results/classifier/118/x86/1387 @@ -0,0 +1,39 @@ +x86: 0.919 +device: 0.891 +architecture: 0.769 +register: 0.742 +graphic: 0.673 +files: 0.649 +network: 0.611 +mistranslation: 0.590 +arm: 0.553 +socket: 0.537 +debug: 0.500 +performance: 0.448 +boot: 0.441 +PID: 0.440 +semantic: 0.429 +ppc: 0.362 +i386: 0.355 +risc-v: 0.327 +user-level: 0.323 +vnc: 0.323 +kernel: 0.296 +permissions: 0.233 +VMM: 0.210 +peripherals: 0.186 +TCG: 0.163 +virtual: 0.134 +assembly: 0.098 +hypervisor: 0.085 +KVM: 0.058 + +QEMU - Add in the FAQ info how to compile Windows x86/x64 installer under Linux Ubuntu +Description of problem: +Please add in the FAQ + +https://wiki.qemu.org/Hosts/W32#Debian_based_cross_builds + +detailed info step by stepo how to create windows x86 and x64 instalelr under Ubuntu +Steps to reproduce: + diff --git a/results/classifier/118/x86/1408152 b/results/classifier/118/x86/1408152 new file mode 100644 index 000000000..3c1dda6cb --- /dev/null +++ b/results/classifier/118/x86/1408152 @@ -0,0 +1,46 @@ +x86: 0.962 +KVM: 0.894 +kernel: 0.831 +boot: 0.806 +network: 0.699 +device: 0.675 +socket: 0.579 +user-level: 0.565 +peripherals: 0.536 +ppc: 0.535 +graphic: 0.521 +architecture: 0.508 +performance: 0.494 +register: 0.492 +mistranslation: 0.449 +semantic: 0.430 +PID: 0.392 +permissions: 0.368 +files: 0.367 +vnc: 0.365 +hypervisor: 0.343 +arm: 0.342 +i386: 0.332 +risc-v: 0.224 +debug: 0.220 +assembly: 0.172 +virtual: 0.172 +TCG: 0.161 +VMM: 0.161 + +latest qemu git doesn't load + +commit ab0302ee764fd702465aef6d88612cdff4302809This is with + +qemu-system-x86_64: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. +/home/njh/bin/kfreebsd-amd64: line 7: 32549 Aborted (core dumped) qemu-system-x86_64 -drive file=kfreebsd-amd64,index=0,media=disk,cache=writeback,aio=native -drive file=/dev/sr0,index=1,media=cdrom -boot c -redir tcp:2232::22 -m 1024 -machine accel=kvm,kernel_irqchip=on -cpu host -net user,hostname=qemu.bandsman.co.uk -net nic,model=e1000 -k en-us + +Seems to be failing to parse kernel_irqchip=on correctly. + +This issue seems to be similar to 1406706 and 1407454. Looks Marcel is working on a fix, and he also posted something to first address USB stuff, + +https://<email address hidden>/msg272607.html + +Hi; we fixed this with commit 446f16a6906e9d0 in March 2015, so I'm going to mark this as fixed. + + diff --git a/results/classifier/118/x86/141 b/results/classifier/118/x86/141 new file mode 100644 index 000000000..a629dc041 --- /dev/null +++ b/results/classifier/118/x86/141 @@ -0,0 +1,31 @@ +x86: 0.924 +device: 0.688 +architecture: 0.641 +network: 0.535 +debug: 0.451 +socket: 0.384 +register: 0.381 +mistranslation: 0.380 +kernel: 0.366 +arm: 0.366 +performance: 0.343 +semantic: 0.333 +graphic: 0.317 +boot: 0.260 +PID: 0.256 +permissions: 0.211 +files: 0.193 +peripherals: 0.165 +vnc: 0.161 +ppc: 0.142 +VMM: 0.113 +assembly: 0.083 +hypervisor: 0.082 +user-level: 0.070 +TCG: 0.061 +risc-v: 0.060 +virtual: 0.025 +i386: 0.007 +KVM: 0.005 + +qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options diff --git a/results/classifier/118/x86/1423528 b/results/classifier/118/x86/1423528 new file mode 100644 index 000000000..15235e607 --- /dev/null +++ b/results/classifier/118/x86/1423528 @@ -0,0 +1,63 @@ +x86: 0.843 +device: 0.801 +architecture: 0.529 +graphic: 0.517 +semantic: 0.501 +PID: 0.439 +performance: 0.350 +KVM: 0.324 +i386: 0.316 +network: 0.313 +user-level: 0.288 +peripherals: 0.275 +register: 0.266 +mistranslation: 0.260 +boot: 0.239 +permissions: 0.232 +socket: 0.217 +ppc: 0.199 +hypervisor: 0.198 +virtual: 0.159 +debug: 0.151 +kernel: 0.137 +files: 0.135 +arm: 0.131 +vnc: 0.120 +risc-v: 0.099 +TCG: 0.082 +assembly: 0.076 +VMM: 0.066 + + 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. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +There's nothing changed in i6300esb about this issue. I can reproduce it exactly the same way with current qemu 5.1-tobe + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/112 + + diff --git a/results/classifier/118/x86/1432103 b/results/classifier/118/x86/1432103 new file mode 100644 index 000000000..467de9ed4 --- /dev/null +++ b/results/classifier/118/x86/1432103 @@ -0,0 +1,38 @@ +x86: 0.979 +permissions: 0.884 +device: 0.653 +register: 0.583 +architecture: 0.505 +network: 0.468 +socket: 0.399 +kernel: 0.398 +graphic: 0.364 +performance: 0.310 +vnc: 0.301 +risc-v: 0.279 +boot: 0.272 +files: 0.262 +debug: 0.242 +ppc: 0.225 +VMM: 0.223 +i386: 0.220 +arm: 0.212 +semantic: 0.211 +hypervisor: 0.177 +PID: 0.176 +assembly: 0.152 +peripherals: 0.148 +KVM: 0.143 +mistranslation: 0.143 +TCG: 0.135 +user-level: 0.108 +virtual: 0.041 + +error in x86 executable segment permission check + +When the code segment register (%cs) selects an executable segment with no read permission, mov instructions that read from the segment via %cs prefix can still succeed without causing a general protection error. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Can you provide a binary to reproduce this issue? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1472 b/results/classifier/118/x86/1472 new file mode 100644 index 000000000..dfdf85188 --- /dev/null +++ b/results/classifier/118/x86/1472 @@ -0,0 +1,35 @@ +x86: 0.970 +graphic: 0.876 +device: 0.834 +network: 0.632 +ppc: 0.614 +kernel: 0.603 +architecture: 0.600 +socket: 0.587 +debug: 0.547 +boot: 0.500 +vnc: 0.495 +VMM: 0.482 +register: 0.473 +mistranslation: 0.436 +hypervisor: 0.409 +performance: 0.409 +arm: 0.391 +semantic: 0.383 +PID: 0.376 +assembly: 0.327 +peripherals: 0.282 +TCG: 0.271 +files: 0.252 +KVM: 0.226 +virtual: 0.217 +risc-v: 0.200 +user-level: 0.122 +permissions: 0.121 +i386: 0.055 + +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/118/x86/1481654 b/results/classifier/118/x86/1481654 new file mode 100644 index 000000000..7bb6a6447 --- /dev/null +++ b/results/classifier/118/x86/1481654 @@ -0,0 +1,71 @@ +x86: 0.909 +ppc: 0.515 +architecture: 0.469 +device: 0.469 +assembly: 0.420 +PID: 0.414 +kernel: 0.408 +register: 0.406 +VMM: 0.402 +permissions: 0.401 +files: 0.397 +hypervisor: 0.392 +graphic: 0.374 +KVM: 0.373 +peripherals: 0.365 +socket: 0.363 +mistranslation: 0.353 +network: 0.328 +i386: 0.322 +boot: 0.287 +virtual: 0.253 +arm: 0.216 +semantic: 0.191 +vnc: 0.182 +performance: 0.159 +TCG: 0.122 +risc-v: 0.115 +debug: 0.106 +user-level: 0.065 + +libcacard.pc paths are not modified when configure prefix is + +Ubuntu Server 15.04 Gnome +Qemu sources from master git://git.qemu-project.org/qemu.git 2.4.0-rc3 SHA 2be4f242 + +Built with: +make distclean +./configure --target-list=x86_64-softmmu \ + --cpu=x86_64 \ + --enable-virtfs \ + --enable-kvm \ + --enable-spice \ + --enable-usb-redir \ + --enable-libusb \ + --audio-drv-list=oss,alsa,sdl,pa \ + --enable-uuid \ + --enable-libnfs \ + --enable-libssh2 \ + --prefix=/usr --sysconfdir=/etc --localstatedir=/var + +make -j6 + +Yet, /usr/lib/libcacard.pc: +prefix=/usr/local +exec_prefix=${prefix} +libdir=/usr/local/lib +includedir=/usr/local/include/cacard + +Name: cacard +Description: CA Card library +Version: 2.3.50 + +Requires.private: nss glib-2.0 +Libs: -L${libdir} -lcacard +Libs.private: +Cflags: -I${includedir} + +This issue affects the building of spice-client-gtk (http://cgit.freedesktop.org/spice/spice-gtk/) which expects correct paths in that file. + +Since QEMU 2.5, libcacard is now an external project (see http://www.spice-space.org/page/Libcacard), so this should not be a problem anymore. + diff --git a/results/classifier/118/x86/1482425 b/results/classifier/118/x86/1482425 new file mode 100644 index 000000000..21bd58db4 --- /dev/null +++ b/results/classifier/118/x86/1482425 @@ -0,0 +1,50 @@ +x86: 0.887 +graphic: 0.860 +device: 0.797 +vnc: 0.789 +socket: 0.765 +network: 0.742 +architecture: 0.736 +performance: 0.546 +mistranslation: 0.497 +ppc: 0.492 +permissions: 0.482 +files: 0.471 +register: 0.444 +semantic: 0.422 +PID: 0.412 +TCG: 0.379 +boot: 0.373 +peripherals: 0.361 +kernel: 0.360 +risc-v: 0.335 +VMM: 0.331 +arm: 0.242 +virtual: 0.241 +debug: 0.236 +hypervisor: 0.231 +user-level: 0.210 +assembly: 0.160 +KVM: 0.027 +i386: 0.022 + +Qemu crashes on Mac (emulation of x86_64) + +I used qemu on MAC OS X Yosemite with the latest qemu version (from git, 6. august 2015, QEMU emulator version 2.3.94, Copyright (c) 2003-2008 Fabrice Bellard) + +I configured it with "./configure --enable-vde". + +Sometimes when starting an openwrt instance, the following error occurrs in the qemu monitor: + +(qemu) qemu:qemu_cpu_kick_thread: No such process + +I started qemu this way: + +qemu-system-x86_64 -m 128 -serial unix:/tmp/qemu_1.sock,server,nowait -nographic -net nic,macaddr=aa:aa:aa:aa:00:01 -net vde,sock=/tmp/vde_switch_1 -watchdog-action poweroff openwrt-x86-generic-combined-ext4.img + +The same works on Linux (Ubuntu 14.04, qemu-2.4.0-rc3). + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1529764 b/results/classifier/118/x86/1529764 new file mode 100644 index 000000000..b672a267d --- /dev/null +++ b/results/classifier/118/x86/1529764 @@ -0,0 +1,45 @@ +x86: 0.824 +graphic: 0.784 +device: 0.781 +virtual: 0.762 +VMM: 0.651 +register: 0.630 +files: 0.627 +peripherals: 0.589 +architecture: 0.588 +hypervisor: 0.554 +permissions: 0.550 +network: 0.525 +mistranslation: 0.509 +PID: 0.485 +performance: 0.482 +semantic: 0.476 +i386: 0.471 +risc-v: 0.447 +socket: 0.430 +vnc: 0.429 +boot: 0.410 +kernel: 0.399 +ppc: 0.371 +user-level: 0.335 +debug: 0.330 +TCG: 0.278 +KVM: 0.274 +arm: 0.267 +assembly: 0.198 + +No video output with the official Windows XP VMWare VGA driver + +Steps to reproduce: + +1) Set -vga to vmware +2) Install Windows XP SP3 +3) Install VGA drivers from http://packages.vmware.com/tools/releases/latest/windows/x86/VMware-tools-windows-10.0.5-3227872.iso + +Result: completely black screen (even after F8 -> use VGA mode). + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1541 b/results/classifier/118/x86/1541 new file mode 100644 index 000000000..0f9f0a7f5 --- /dev/null +++ b/results/classifier/118/x86/1541 @@ -0,0 +1,62 @@ +x86: 0.970 +ppc: 0.915 +graphic: 0.817 +hypervisor: 0.801 +architecture: 0.789 +i386: 0.781 +files: 0.765 +device: 0.752 +permissions: 0.722 +mistranslation: 0.626 +semantic: 0.599 +register: 0.556 +network: 0.553 +vnc: 0.539 +debug: 0.529 +PID: 0.485 +assembly: 0.475 +socket: 0.467 +TCG: 0.461 +risc-v: 0.451 +VMM: 0.439 +kernel: 0.433 +peripherals: 0.419 +arm: 0.384 +user-level: 0.383 +performance: 0.379 +KVM: 0.312 +virtual: 0.289 +boot: 0.230 + +Invalid position of G_NORETURN in clang v15 +Description of problem: +Order of `G_NORETURN` used in https://gitlab.com/qemu-project/qemu/-/blob/0f3de970febd2c9b29dccecb63ca928c6802a101/include/qemu/osdep.h#L240-242 is not valid in clang++ 15.0.7. + +Switching `extern` with `G_NORETURN` seems to fix the issue. +Steps to reproduce: +1. Build qemu system for MIPSEL or use minimal reproducer: + +`example.cpp`: +``` +#include "/path/to/qemu/include/glib-compat.h" + +extern G_NORETURN +void // QEMU_ERROR("code path is reachable") + qemu_build_not_reached_always(void); +``` + +``` +$ clang++ --version +clang version 15.0.7 +Target: x86_64-pc-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +$ clang++ -m64 -mcx16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu++11 -O0 -g example.cpp +example.cpp:3:8: error: an attribute list cannot appear here +extern G_NORETURN + ^~~~~~~~~~ +/usr/include/glib-2.0/glib/gmacros.h:1075:21: note: expanded from macro 'G_NORETURN' +# define G_NORETURN [[noreturn]] + ^~~~~~~~~~~~ +1 error generated. +``` diff --git a/results/classifier/118/x86/1626596 b/results/classifier/118/x86/1626596 new file mode 100644 index 000000000..4d618782a --- /dev/null +++ b/results/classifier/118/x86/1626596 @@ -0,0 +1,53 @@ +x86: 0.934 +i386: 0.862 +KVM: 0.826 +graphic: 0.808 +vnc: 0.762 +device: 0.761 +hypervisor: 0.747 +virtual: 0.737 +network: 0.710 +performance: 0.703 +debug: 0.681 +architecture: 0.645 +mistranslation: 0.620 +kernel: 0.608 +PID: 0.608 +files: 0.592 +semantic: 0.580 +user-level: 0.574 +ppc: 0.557 +register: 0.519 +socket: 0.514 +VMM: 0.511 +peripherals: 0.502 +permissions: 0.490 +assembly: 0.471 +risc-v: 0.451 +boot: 0.429 +TCG: 0.415 +arm: 0.378 + +Lockup with vhost network + +After using Qemu in this configuration successfully for quite a while, I changed two things: +- moved the VM from a 8-core 4GHz host to a slower 2-core 1.6 Ghz machine +- upgraded qemu from 2.1 to 2.5 + +and almost immediately (in a couple hours) got hit with a vhost-related lockup. + +QEMU command line is: + +qemu-system-x86_64 -enable-kvm -daemonize -monitor unix:./monitor,server,nowait -cpu host -M q35 -balloon virtio -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd -drive if=none,id=hd,cache=writeback,aio=native,format=raw,file=xxxx.img,discard=unmap,detect-zeroes=unmap -device virtio-net-pci,netdev=net0,mac=xxxx -netdev tap,vhost=on,id=net0,script=xxxx.sh -usbdevice tablet -smp 2 -m 512 -vnc xxxx:yz + +VM was running fine, except no network traffic was passed from/to it. Shutting down the VM, it hung at "Will now halt." The QEMU process was unkillable, so the only choice was to sysrq-b the entire box. + +dmesg with sysrq-w attached. + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1631 b/results/classifier/118/x86/1631 new file mode 100644 index 000000000..c63af7b5d --- /dev/null +++ b/results/classifier/118/x86/1631 @@ -0,0 +1,47 @@ +x86: 0.830 +arm: 0.756 +device: 0.737 +graphic: 0.621 +boot: 0.603 +mistranslation: 0.562 +performance: 0.397 +PID: 0.271 +semantic: 0.231 +architecture: 0.229 +network: 0.214 +socket: 0.197 +debug: 0.185 +vnc: 0.180 +permissions: 0.179 +register: 0.156 +hypervisor: 0.133 +ppc: 0.133 +files: 0.128 +risc-v: 0.125 +user-level: 0.112 +VMM: 0.099 +virtual: 0.090 +kernel: 0.084 +TCG: 0.068 +peripherals: 0.049 +i386: 0.031 +assembly: 0.030 +KVM: 0.017 + +[8.0.0] Host MacOS 13.3.1 – does not work or works incorrectly +Description of problem: +WINXP x86 - freezes before logging in on ARM macOS 13.3.1 host + +WINXP x86 - works but slowly x86_64 macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after start on ARM macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after selecting grub boot option + +**On qemu 7.2.1 all works perfectly!!!** +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/x86/1645355 b/results/classifier/118/x86/1645355 new file mode 100644 index 000000000..b452e9fb0 --- /dev/null +++ b/results/classifier/118/x86/1645355 @@ -0,0 +1,89 @@ +x86: 0.843 +architecture: 0.789 +kernel: 0.788 +files: 0.750 +device: 0.746 +permissions: 0.744 +mistranslation: 0.740 +graphic: 0.738 +performance: 0.732 +user-level: 0.723 +semantic: 0.721 +PID: 0.691 +hypervisor: 0.682 +register: 0.680 +debug: 0.678 +peripherals: 0.670 +risc-v: 0.664 +vnc: 0.658 +ppc: 0.639 +socket: 0.636 +arm: 0.601 +TCG: 0.582 +boot: 0.572 +assembly: 0.571 +virtual: 0.554 +VMM: 0.527 +i386: 0.492 +KVM: 0.487 +network: 0.484 + +x86: singlestepping through SYSCALL instruction causes exception in kernelspace + +Hi, + +The bug was originally reported [1] and [2] here. There is a problem inside QEMU with singlestepping from userspace until SYSCALL instruction is reached. The OS has in FMASK TF bit set, therefore there should be no singlestepping exception when transitioning to kernelmode. But, inside QEMU there is (TF is clear seems FMASK is applied). See below for further details. + +The reproducer is available at [2]. + +Here is the original text with some minor clarifications: + +It seems that there is something wrong with QEMU with respect to handle the singlestepping and AMD64 syscall instruction. + +The AMD "syscall" instruction will clear defined flag in the FMASK MSR. Normally the TF flag is set there, so the first instruction when kernel is entered after syscall won't cause single step exception in the kernel. + +The observed scenario is a unhandled singlestep fault in the kernel or host reboot or QEMU crash. + +The possible way how to reproduce it is to single step through any function (in userspace) which does "syscall" instruction. After syscall is entered QEMU will trigger singlestepping exception in the kernel despite that the TF is set in FMASK MSR. Real HW behaves correctly and does not trigger this exception. + + +What is interesting is that I was not able to trigger it if I just enabled TF and did the syscall instruction, perhaps for this bug is somewhat important to have TF set for previous few instruction. + + +I have stumbled to this problem while working with our custom OS. However after some googling I found out that the NetBSD guys (CCed) are having very similar problem and I asked them to prepare a ISO image where the problem ends with QEMU SIGSEGV or host reboot. + +Thanks +Rudolf + +[1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html +[2] http://gnats.netbsd.org/49603 + +I believe this is fixed in the qemu git mainline (but not yet in any release) +by the following commits: + + commit c52ab08aee6f7d4717fc6b517174043126bd302f + Author: Doug Evans <email address hidden> + Date: Tue Dec 6 23:06:30 2016 +0000 + + target-i386: Fix eflags.TF/#DB handling of syscall/sysret insns + + The syscall and sysret instructions behave a bit differently: + TF is checked after the instruction completes. + This allows the o/s to disable #DB at a syscall by adding TF to FMASK. + And then when the sysret is executed the #DB is taken "as if" the + syscall insn just completed. + + commit 410e98146ffde201ab4c778823ac8beaa74c4c3f + Author: Doug Evans <email address hidden> + Date: Sat Dec 24 20:29:33 2016 +0000 + + target/i386: Fix bad patch application to translate.c + + In commit c52ab08aee6f7d4717fc6b517174043126bd302f, + the patch snippet for the "syscall" insn got applied to "iret". + + +Hi Andreas, man thanks for your reply. I can confirm that applying the two patches fixes my problem in the older version of the QEMU. + +The two patches mentioned in comment #1 have been released with v2.9.0, so setting status to "Fix released" now. + diff --git a/results/classifier/118/x86/1649236 b/results/classifier/118/x86/1649236 new file mode 100644 index 000000000..74be292c7 --- /dev/null +++ b/results/classifier/118/x86/1649236 @@ -0,0 +1,57 @@ +x86: 0.904 +permissions: 0.852 +ppc: 0.784 +files: 0.780 +vnc: 0.746 +i386: 0.739 +device: 0.728 +performance: 0.709 +semantic: 0.653 +KVM: 0.633 +network: 0.616 +socket: 0.613 +PID: 0.613 +mistranslation: 0.604 +register: 0.604 +kernel: 0.589 +architecture: 0.588 +virtual: 0.564 +user-level: 0.563 +graphic: 0.546 +peripherals: 0.534 +hypervisor: 0.522 +VMM: 0.481 +risc-v: 0.461 +TCG: 0.421 +debug: 0.394 +boot: 0.389 +arm: 0.352 +assembly: 0.310 + +Commit snapshot fails with Permission denied when daemonized + +When running qemu with daemonize option it is impossible to run "commit all" in monitor. + +I run qemu 2.7.0 under gentoo 64 bit distribution with following command line: + +qemu-system-x86_64 -m 4096 -cpu host -smp 2 -enable-kvm -snapshot \ + -drive file=vm.img,if=virtio \ + -net nic,model=virtio,macaddr=11:11:11:11:11:11 \ + -net tap,ifname=tap$PORT,script=no,downscript=no \ + -vnc :1 -daemonize \ + -chardev vc,id=mon0 -mon chardev=mon0,mode=readline \ + -chardev socket,id=mon1,host=localhost,port=10001,server,nowait -mon chardev=mon1,mode=control + +I connect to vm through VNC viewer and press CTRL+ALT+2 and run "commit all" command. +Following error is shown: +`commit` error for `all`: Permission denied + +When I run my VM without `daemonize` option the command "commit all" works without errors. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1686364 b/results/classifier/118/x86/1686364 new file mode 100644 index 000000000..080fc77fb --- /dev/null +++ b/results/classifier/118/x86/1686364 @@ -0,0 +1,56 @@ +x86: 0.929 +files: 0.867 +device: 0.852 +architecture: 0.664 +network: 0.642 +kernel: 0.593 +graphic: 0.546 +performance: 0.526 +ppc: 0.478 +semantic: 0.470 +socket: 0.450 +vnc: 0.397 +mistranslation: 0.385 +hypervisor: 0.377 +virtual: 0.370 +permissions: 0.295 +debug: 0.293 +register: 0.269 +risc-v: 0.263 +boot: 0.261 +PID: 0.259 +VMM: 0.257 +i386: 0.253 +TCG: 0.251 +user-level: 0.223 +peripherals: 0.223 +KVM: 0.213 +arm: 0.192 +assembly: 0.054 + +qemu -readconfig/-writeconfig cannot handle quotes in values + +$ qemu-system-x86_64 -drive file=/tmp/foo\" -writeconfig - +# qemu config file + +[drive] + file = "/tmp/foo"" + +For bonus points, try to construct a value qemu config file that contains a quoted value. It's pretty clear (from looking at the code also) that this is not possible. + +Also: + +- maximum value length is hard-coded in the parser at 1023 characters (for no apparent reason) + +- the format is undocumented + +- don't use sscanf for parsing! + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/142 + + diff --git a/results/classifier/118/x86/1687 b/results/classifier/118/x86/1687 new file mode 100644 index 000000000..fb429b508 --- /dev/null +++ b/results/classifier/118/x86/1687 @@ -0,0 +1,83 @@ +x86: 0.946 +graphic: 0.840 +device: 0.833 +arm: 0.818 +architecture: 0.784 +PID: 0.726 +semantic: 0.651 +permissions: 0.603 +ppc: 0.590 +debug: 0.560 +vnc: 0.552 +performance: 0.476 +kernel: 0.453 +assembly: 0.384 +register: 0.375 +socket: 0.329 +peripherals: 0.313 +network: 0.311 +VMM: 0.288 +user-level: 0.247 +risc-v: 0.201 +hypervisor: 0.182 +mistranslation: 0.159 +boot: 0.128 +files: 0.102 +TCG: 0.068 +virtual: 0.063 +KVM: 0.042 +i386: 0.026 + +Memory leak for x86 guest on macOS ARM host +Description of problem: +QEMU is used by docker to run `x86` binaries on Apple silicon. Then using `mmap` followed by `munmap` results in a memory leak manifested by continuously growing RSS memory usage when running `mmap` and `munmap` in a loop, e.g., when running the following binary: + +``` +#include <stdio.h> +#include <unistd.h> +#include <sys/mman.h> + +const int page = 4096; + +int work(int N) { + int *ptr = mmap(NULL, N * sizeof(int), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); + + if (ptr == MAP_FAILED) { + printf("Mapping Failed\n"); + return 1; + } + + for(int i = 0; i < N; i++) { + ptr[i] = i * 10; + } + + int err = munmap(ptr, N * sizeof(int)); + if (err != 0) { + printf("UnMapping Failed\n"); + return 1; + } + + return 0; +} + +int main() { + int N = page * 1024; + + while (1) { + int res = work(N); + if (res) { + return res; + } + printf(".\n"); + } + + return 0; +} +``` +Steps to reproduce: +``` +$ LEAK=$(docker run --platform linux/amd64 -d -it martin2718/mmap-leak ./a.out) +$ docker exec -it $LEAK top # you should observe that RES for a.out keeps growing +$ docker exec -it $LEAK pmap -x 1 # you should see a single memory mapping whose RSS memory usage keeps growing +$ docker kill $LEAK # abort the experiment +``` diff --git a/results/classifier/118/x86/1699567 b/results/classifier/118/x86/1699567 new file mode 100644 index 000000000..166d3220c --- /dev/null +++ b/results/classifier/118/x86/1699567 @@ -0,0 +1,62 @@ +x86: 0.938 +device: 0.765 +architecture: 0.762 +socket: 0.608 +mistranslation: 0.606 +ppc: 0.580 +hypervisor: 0.572 +semantic: 0.565 +performance: 0.560 +debug: 0.541 +user-level: 0.534 +register: 0.533 +i386: 0.531 +graphic: 0.530 +risc-v: 0.523 +files: 0.519 +vnc: 0.506 +virtual: 0.495 +peripherals: 0.485 +network: 0.461 +assembly: 0.460 +PID: 0.453 +VMM: 0.451 +arm: 0.424 +permissions: 0.421 +boot: 0.421 +kernel: 0.420 +TCG: 0.374 +KVM: 0.160 + +Qemu does not force SSE data alignment + +I have an OS that tries to use SSE operations. It works fine in qemu. But it crashes when I try to run the OS at the host cpu using KVM. + +The instruction that crahes with #GP(0) is + movaps ADDR,%xmm0 + +The documentation says ADDR has to be 16-bytes alignment otherwise #GP is generated. And indeed the problem was with the data alignment. After adjusting it at my side the OS works fine both with Qemu and KVM. + +It would be great if QEMU followed specification more closely and forced SSE data alignment requirements. It will help to catch alignment issues early and debug it easier. + + +$ qemu-system-x86_64 -version +QEMU emulator version 2.9.50 (v2.9.0-1363-g95eef1c68b) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +I am currently running into this bug on QEMU emulator version 5.1.0. +movaps unaligned access works fine in qemu, when it should throw a GP. Likewise, the same code on physical hardware throws a GP. + +Yep. Long-standing bug. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/217 + + diff --git a/results/classifier/118/x86/1701973 b/results/classifier/118/x86/1701973 new file mode 100644 index 000000000..82d933e34 --- /dev/null +++ b/results/classifier/118/x86/1701973 @@ -0,0 +1,68 @@ +x86: 0.881 +performance: 0.508 +semantic: 0.360 +socket: 0.337 +device: 0.335 +ppc: 0.311 +user-level: 0.296 +network: 0.278 +peripherals: 0.255 +architecture: 0.250 +hypervisor: 0.247 +PID: 0.234 +graphic: 0.228 +files: 0.227 +permissions: 0.225 +i386: 0.225 +kernel: 0.218 +mistranslation: 0.214 +risc-v: 0.204 +boot: 0.198 +VMM: 0.182 +vnc: 0.177 +assembly: 0.173 +virtual: 0.170 +register: 0.166 +debug: 0.157 +KVM: 0.149 +arm: 0.139 +TCG: 0.117 + +pread does not work right under qemu-sh4 + +The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread + +Expected output: +ret=1 errno=0 + +Actual output: +ret=0 errno=2 +test-pread.c:44: assertion 'ret == 1' failed +qemu: uncaught target signal 6 (Aborted) - core dumped + + + + + +In case it matters: My host platform is Linux/x86_64. + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +This might be related to this fix: + +> https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0 + +FWIW, if you're interested in sh4, please join #debian-ports on OFTC and subscribe to the debian-superh mailing list. We're doing lots of sh4 development and testing QEMU in Debian. + +With qemu-2.11: +$ ~/inst-qemu/2.11.0/bin/qemu-sh4 test-pread +ret=1 errno=2 + +The value of errno is actually irrelevant here. So, the bug is fixed. + diff --git a/results/classifier/118/x86/1724477 b/results/classifier/118/x86/1724477 new file mode 100644 index 000000000..efb585061 --- /dev/null +++ b/results/classifier/118/x86/1724477 @@ -0,0 +1,74 @@ +x86: 0.944 +network: 0.855 +vnc: 0.852 +device: 0.822 +socket: 0.798 +kernel: 0.794 +KVM: 0.774 +architecture: 0.763 +performance: 0.743 +permissions: 0.640 +i386: 0.626 +PID: 0.617 +ppc: 0.585 +risc-v: 0.555 +hypervisor: 0.552 +peripherals: 0.533 +semantic: 0.506 +files: 0.472 +arm: 0.465 +VMM: 0.457 +register: 0.455 +boot: 0.454 +user-level: 0.414 +mistranslation: 0.385 +virtual: 0.316 +graphic: 0.306 +assembly: 0.304 +TCG: 0.285 +debug: 0.159 + +Build-in websocket broken since v2.9.0-rc0 + +Since upgrading to 2.9.0, the qemu's build-in websocket was no longer available. + +Host: Ubuntu 16.04 LTS +Command-line: /bin/qemu-system-x86_64 -enable-kvm -vnc 0.0.0.0:8,websocket + +I have tested the following qemu versions: + +master Fail +2.10.1 Fail +2.9.1 Fail +2.9.0 Fail +2.9.0-rc3 Fail +2.9.0-rc0 Fail + +2.8.1.1 Pass +2.7.1 Pass +2.6.2 Pass + + + + + +Note that we tightened up the websocket server impl to validate HTTP requests more strictly. One key change is that the websockets path is required to be empty, while noVNC will default to appending a path - so make sure you change noVNC to have an empty path. Also until GIT master yesterday, there was a bug that prevented it working if the client requested keep-alive, which I see noVNC now does. So if you try git master today, it ought to work. + +Awesome! I cleared the path and tried the latest version, now it works! +BTW, is there any other VNC Web Client that I can choose? or noVNC is the one and only? + +Key fixes for client interoperability coming in 2.11 include + + +6d5d23b00709510d55711661c7ca41408fd9934e io: cope with websock 'Connection' header having multiple values +530ca60c16c83435d4becc9916d74fa43e003815 io: Attempt to send websocket close messages to client +268a53f50de795481dd73ffd0e0c1339ad3dc44b io: Reply to ping frames +01af17fc002414ee1ac0800babfb0edc2bef1a7d io: Ignore websocket PING and PONG frames +3a29640e2cbae9d47b89ffaf98ed358920eb6797 io: Allow empty websocket payload +ff1300e626949fa9850b0f91dc5e8c2cb45b6a88 io: Add support for fragmented websocket binary frames +eefa3d8ef649f9055611361e2201cca49f8c3433 io: Small updates in preparation for websocket changes +33badfd1e3735b877e41939100511c65572be6b9 io: use case insensitive check for Connection & Upgrade websock headers +3a3f8705962c8c8a47a9b981ffd5aab7274ad508 io: include full error message in websocket handshake trace +f69a8bde29354493ff8aea64cc9cb3b531d16337 io: send proper HTTP response for websocket errors + + diff --git a/results/classifier/118/x86/1725 b/results/classifier/118/x86/1725 new file mode 100644 index 000000000..d7259a0ba --- /dev/null +++ b/results/classifier/118/x86/1725 @@ -0,0 +1,51 @@ +x86: 0.925 +graphic: 0.831 +debug: 0.783 +architecture: 0.763 +performance: 0.749 +semantic: 0.703 +device: 0.694 +user-level: 0.649 +hypervisor: 0.641 +socket: 0.572 +register: 0.550 +kernel: 0.548 +mistranslation: 0.522 +virtual: 0.520 +network: 0.501 +permissions: 0.500 +risc-v: 0.484 +VMM: 0.462 +PID: 0.459 +vnc: 0.459 +ppc: 0.455 +assembly: 0.439 +peripherals: 0.435 +files: 0.415 +KVM: 0.369 +TCG: 0.332 +arm: 0.331 +i386: 0.264 +boot: 0.260 + +qemu-system-x86_64 reports wrong thread to GDB on SIGINT +Description of problem: +Upon interruption of a thread by GDB, QEMU in some circumstances will send a stop reply with the ID of a thread that had not been resumed. + +This happens for the following reasons: +1. GDB uses `vCont` exclusively to resume and step through threads. +2. When a thread is interrupted by GDB, QEMU runs `vm_stop(RUN_STATE_PAUSED)`, which triggers `gdb_vm_state_change`, which, in turn, uses whatever CPU is pointed to by `gdbserver_state.c_cpu` at that time to construct the stop reply. +3. The `vCont` handler in QEMU doesn't set `gdbserver_state.c_cpu` before resuming any CPUs. + +Important to note is that stepping is not affected by this issue because the `EXCP_DEBUG` handler sets `gdbserver_state.c_cpu` to the CPU the exception happened in before `gdb_vm_state_change` runs. Which also means single stepping before continuing is an effective way to work around this bug. +Steps to reproduce: +1. Run QEMU with at least two threads and the GDB stub enabled. +2. Run `gdb --nx --ex 'target remote :1234' --ex 'set scheduler-locking on'` +3. Switch to Thread 1.2 in GDB with `thr 2` +4. Resume Thread 1.2 in GDB with `c` +5. Press Ctrl+C to interrupt the VM +6. Notice that the event is reported as having happened in Thread 1.1, which has not been resumed. +Additional information: +Note that, while this bug happens no matter the state of `scheduler-locking`, it only becomes a problem when it is enabled. This is because, when it is disabled, GDB will always resume all threads on `continue`, so it doesn't matter what thread ID QEMU says the interrupt happened in, as it is guaranteed to have been resumed anyway. That, however, is not the case when `scheduler-locking` is enabled. + +Regardless, I don't think it makes sense for QEMU to be reporting events happening in threads that weren't resumed through either `s/S/c/C` or `vCont`, which is what it's doing here. diff --git a/results/classifier/118/x86/1735082 b/results/classifier/118/x86/1735082 new file mode 100644 index 000000000..3fd439f49 --- /dev/null +++ b/results/classifier/118/x86/1735082 @@ -0,0 +1,59 @@ +x86: 0.938 +vnc: 0.740 +architecture: 0.734 +virtual: 0.692 +VMM: 0.657 +device: 0.647 +network: 0.623 +kernel: 0.601 +mistranslation: 0.578 +graphic: 0.481 +ppc: 0.462 +files: 0.432 +semantic: 0.425 +permissions: 0.398 +socket: 0.384 +performance: 0.362 +PID: 0.334 +hypervisor: 0.312 +KVM: 0.308 +register: 0.296 +boot: 0.296 +peripherals: 0.272 +arm: 0.218 +user-level: 0.194 +assembly: 0.184 +debug: 0.176 +risc-v: 0.169 +TCG: 0.159 +i386: 0.089 + +NVME pass through in th eguest VM + +Hi Qemu Team + +i am new in qemu and trying for nvme pass through .. +for that i used below git repo for nvme + +https://github.com/famz/qemu/tree/nvme + +and trying to launch the VM by below qemu command .. + +/usr/local/bin/qemu-system-x86_64 -name sl7.0 -m 1024 -object memory-backend-file,id=mem,size=1G,mem-path=/dev/hugepages,share=on -nographic -no-user-config -nodefaults -serial mon:telnet:localhost:7704,server,nowait -monitor mon:telnet:localhost:8804,server,nowait -numa node,memdev=mem -drive file=/home/qemu/qcows,format=qcow2,if=none,id=disk -device ide-hd,drive=disk,bootindex=0 -drive file=nvme://0000:d8:00.0,if=none,id=drive0 -device virtio-blk,drive=drive0,id=virtio0 --enable-kvm + +i am getting kernel panic and not proceed further..please help + +PS:- our guest VM version is + +Scientific Linux 7.0 (Nitrogen) +Kernel 3.10.0-123.el7.x86_64 on an x86_64 + +Regards +Nitin + + + +Can you reproduce the problem with the latest official upstream version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1738767 b/results/classifier/118/x86/1738767 new file mode 100644 index 000000000..6468e0f78 --- /dev/null +++ b/results/classifier/118/x86/1738767 @@ -0,0 +1,58 @@ +x86: 0.837 +user-level: 0.793 +arm: 0.787 +graphic: 0.769 +device: 0.733 +semantic: 0.718 +ppc: 0.681 +kernel: 0.671 +files: 0.669 +architecture: 0.651 +socket: 0.635 +network: 0.632 +performance: 0.625 +mistranslation: 0.572 +register: 0.569 +VMM: 0.568 +risc-v: 0.523 +vnc: 0.505 +PID: 0.503 +permissions: 0.488 +hypervisor: 0.485 +peripherals: 0.472 +boot: 0.470 +virtual: 0.462 +TCG: 0.403 +i386: 0.381 +debug: 0.366 +KVM: 0.308 +assembly: 0.307 + +Cannot build QEMU on RHEL6 because of MAP_HUGETLB + +Hello, +I've just downloaded qemu-2.11.0 sources and I wanted to build QEMU on RHEL6 x86_64, for various targets, amonst which arm-linux-user. + +The build fails because /usr/include/bits/mman.h does not define MAP_HUGETLB. + +I think it is needed since commit 541e16904. + +I'm not sure if RHEL6 is still supported by QEMU? If so, can you fix this problem? + +Thanks + +I think we can close this bug: the build fails on RHEL6.4, but succeeded on RHEL6.7. + +Probably related to: https://access.redhat.com/solutions/320613 + +This was fixed by the distro updating their glibc-headers pakcage: + +* Tue Jul 23 2013 Alexandre Oliva <email address hidden> - 2.12-1.119 +- Add MAP_HUGETLB and MAP_STACK support (#916986). +- Update translation for stale file handle error (#970776). + +The build works in the current centos6 docker image and has been confirmed to build on later RHEL6 (RHEL6.7). + +OK, since we work on more recent RHEL6 and the submitter is happy with that, let's close this bug as WONTFIX. + + diff --git a/results/classifier/118/x86/1751422 b/results/classifier/118/x86/1751422 new file mode 100644 index 000000000..14a1b22ce --- /dev/null +++ b/results/classifier/118/x86/1751422 @@ -0,0 +1,88 @@ +x86: 0.810 +i386: 0.716 +mistranslation: 0.597 +semantic: 0.524 +graphic: 0.506 +socket: 0.497 +architecture: 0.490 +user-level: 0.473 +kernel: 0.468 +device: 0.451 +files: 0.441 +vnc: 0.425 +register: 0.423 +debug: 0.419 +ppc: 0.416 +PID: 0.400 +hypervisor: 0.390 +network: 0.386 +virtual: 0.384 +permissions: 0.383 +risc-v: 0.373 +performance: 0.360 +arm: 0.355 +boot: 0.348 +peripherals: 0.344 +TCG: 0.336 +assembly: 0.324 +VMM: 0.305 +KVM: 0.292 + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. + +Could you please provide some more information about the problem? What's exactly the error? If you've already got a patch, please have a look at https://wiki.qemu.org/Contribute/SubmitAPatch to get some information how to submit it. + +The patch is In this mail attachments, which is patch for version 2.11.1 target/i386/translate.c. +The patch is created by diff. +my English is so poor to explain how the error come, but you can see the patch result to get it. + + + + + + + + +At 2018-02-25 17:41:15, "Thomas Huth" <email address hidden> wrote: +>Could you please provide some more information about the problem? What's +>exactly the error? If you've already got a patch, please have a look at +>https://wiki.qemu.org/Contribute/SubmitAPatch to get some information +>how to submit it. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1751422 +> +>Title: +> some instructions translate error in x86 +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +> The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1751422/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + +We shouldn't really have let this expire, the submitter has a patch attached to the bug. + +Yabi: do you have a simple test program which fails without this patch and works with it? If so can you attach it to the bug ? + + +I believe this to be fixed by cfcca361d77, which is present in 2.12 but not 2.11. + +Since Richard pointed out a commit which fixed this in 2.12 and we haven't heard back from the submitter, I'm going to close this bug as fixed. + + diff --git a/results/classifier/118/x86/1756728 b/results/classifier/118/x86/1756728 new file mode 100644 index 000000000..e89430fac --- /dev/null +++ b/results/classifier/118/x86/1756728 @@ -0,0 +1,52 @@ +x86: 0.895 +KVM: 0.838 +device: 0.794 +graphic: 0.772 +performance: 0.759 +ppc: 0.715 +mistranslation: 0.710 +PID: 0.700 +architecture: 0.662 +register: 0.629 +kernel: 0.627 +user-level: 0.620 +semantic: 0.610 +network: 0.605 +permissions: 0.591 +assembly: 0.575 +debug: 0.572 +files: 0.568 +virtual: 0.565 +socket: 0.562 +boot: 0.554 +i386: 0.533 +arm: 0.507 +peripherals: 0.504 +hypervisor: 0.495 +TCG: 0.493 +risc-v: 0.468 +VMM: 0.446 +vnc: 0.440 + +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 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1759333 b/results/classifier/118/x86/1759333 new file mode 100644 index 000000000..9dd61f76d --- /dev/null +++ b/results/classifier/118/x86/1759333 @@ -0,0 +1,51 @@ +x86: 0.802 +device: 0.737 +graphic: 0.659 +i386: 0.646 +performance: 0.614 +architecture: 0.591 +hypervisor: 0.581 +register: 0.551 +semantic: 0.549 +permissions: 0.497 +network: 0.494 +files: 0.492 +vnc: 0.478 +socket: 0.475 +kernel: 0.467 +ppc: 0.450 +PID: 0.431 +boot: 0.429 +virtual: 0.398 +risc-v: 0.396 +mistranslation: 0.382 +peripherals: 0.382 +user-level: 0.344 +debug: 0.334 +arm: 0.320 +VMM: 0.303 +TCG: 0.263 +assembly: 0.244 +KVM: 0.205 + +Illegal Instruction with HVF when encountering SSE instructions in the emulator + +The latest version of QEMU doesn't seem to support emulated SSE instructions with HVF acceleration on macOS. +The decoder will treat SSE instructions as invalid, get the instruction sizes wrong and quickly crash the guest OS because of illegal instructions. +After having a quick look at target/i386/hvf/x86_decode.c, it seems that SSE instruction emulation isn't implemented in the current version of the x86 emulator. + +A way to reproduce the issue is to run a macOS 10.13 guest with HVF acceleration enabled, this will crash once it's loading up the GUI. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +Thomas, I think the issue is there. SSE/MMX weren't yet added for HVF. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/150 + + diff --git a/results/classifier/118/x86/1764 b/results/classifier/118/x86/1764 new file mode 100644 index 000000000..3699580c1 --- /dev/null +++ b/results/classifier/118/x86/1764 @@ -0,0 +1,31 @@ +x86: 0.870 +device: 0.861 +architecture: 0.559 +peripherals: 0.538 +performance: 0.433 +debug: 0.424 +graphic: 0.366 +network: 0.322 +semantic: 0.230 +VMM: 0.222 +arm: 0.188 +ppc: 0.185 +virtual: 0.179 +PID: 0.177 +socket: 0.154 +mistranslation: 0.134 +TCG: 0.132 +hypervisor: 0.104 +register: 0.088 +boot: 0.078 +kernel: 0.068 +permissions: 0.056 +vnc: 0.048 +KVM: 0.045 +user-level: 0.042 +files: 0.028 +i386: 0.025 +assembly: 0.018 +risc-v: 0.015 + +lsusb fails with qemu-system-x86_64 command (qemu-system-x86 package) diff --git a/results/classifier/118/x86/1767126 b/results/classifier/118/x86/1767126 new file mode 100644 index 000000000..93766eba2 --- /dev/null +++ b/results/classifier/118/x86/1767126 @@ -0,0 +1,45 @@ +x86: 0.913 +mistranslation: 0.744 +graphic: 0.618 +semantic: 0.476 +device: 0.433 +peripherals: 0.380 +performance: 0.369 +architecture: 0.362 +user-level: 0.333 +risc-v: 0.195 +debug: 0.191 +i386: 0.186 +network: 0.182 +ppc: 0.163 +permissions: 0.158 +TCG: 0.154 +boot: 0.115 +register: 0.101 +PID: 0.098 +virtual: 0.090 +VMM: 0.089 +kernel: 0.087 +hypervisor: 0.085 +files: 0.068 +arm: 0.063 +vnc: 0.042 +socket: 0.042 +KVM: 0.026 +assembly: 0.016 + +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. + +The -drive if=scsi still works on the machines that have a SCSI bus by default. And the change for x86 has been documented in the ChangeLog: https://wiki.qemu.org/ChangeLog/2.12 + diff --git a/results/classifier/118/x86/1785 b/results/classifier/118/x86/1785 new file mode 100644 index 000000000..0cb8e1dfe --- /dev/null +++ b/results/classifier/118/x86/1785 @@ -0,0 +1,55 @@ +x86: 0.957 +device: 0.868 +files: 0.846 +kernel: 0.820 +graphic: 0.803 +architecture: 0.786 +performance: 0.775 +i386: 0.774 +network: 0.748 +mistranslation: 0.745 +PID: 0.733 +KVM: 0.732 +hypervisor: 0.724 +register: 0.720 +risc-v: 0.703 +debug: 0.701 +socket: 0.687 +boot: 0.687 +TCG: 0.685 +VMM: 0.649 +permissions: 0.624 +peripherals: 0.614 +arm: 0.605 +ppc: 0.604 +vnc: 0.602 +semantic: 0.557 +assembly: 0.522 +user-level: 0.493 +virtual: 0.300 + +8.1.0rc0: Build failure when building static binaries, auto config incorrectly mark bzip2 as supported on my machine +Description of problem: +8.1.0rc0 fails to build when I build static binaries. + +``` +Jul 24 20:28:22 clang-13: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument] +Jul 24 20:28:22 ld.lld: error: attempted static link of dynamic object /usr/bin/../lib/libbz2.so +Jul 24 20:28:22 clang-13: error: linker command failed with exit code 1 (use -v to see invocation) +``` + +It seems that `./configure` mistaken my dynamic library of bzip2 as able to compile under static compilation. +Steps to reproduce: +1. `./configure --target-list=x86_64-softmmu --static` with bzip2 only dynamicly installed and static library not installed +2. see output + +You can see +``` + snappy support : NO + bzip2 support : YES + lzfse support : NO +``` + +which is wrong. Additionally, the compilation fails because the system only have bzip2 dynamicly but not staticly. +Additional information: + diff --git a/results/classifier/118/x86/1812694 b/results/classifier/118/x86/1812694 new file mode 100644 index 000000000..a8ddbf4f3 --- /dev/null +++ b/results/classifier/118/x86/1812694 @@ -0,0 +1,46 @@ +x86: 0.875 +performance: 0.813 +graphic: 0.777 +mistranslation: 0.587 +device: 0.536 +semantic: 0.518 +files: 0.501 +architecture: 0.424 +i386: 0.406 +socket: 0.358 +boot: 0.318 +network: 0.311 +vnc: 0.239 +permissions: 0.226 +virtual: 0.222 +ppc: 0.219 +user-level: 0.206 +register: 0.192 +PID: 0.162 +peripherals: 0.129 +kernel: 0.128 +debug: 0.122 +risc-v: 0.120 +VMM: 0.112 +hypervisor: 0.106 +arm: 0.104 +assembly: 0.104 +TCG: 0.074 +KVM: 0.033 + +qemu-system-x86_64 version 3.0+ is 20 times slower than version 2.12 + +version 3.0+ is 20 times slower than version 2.12 +I wrote a small 64-bit operating system (SIGMAOS) in which I use the lzma decoder. unpacking the file takes 20 times slower than in version 2.12. +You can download it from https://drive.google.com/drive/folders/0B_wEiYjzVkC0ZGtkbENENzF1Nms + +Your linked drive doesn't seem to have any readme or documentation for how this is invoked. Please see: + + https://www.qemu.org/contribute/report-a-bug/ + +Specifically the host/guest details and the full command line that you have used to run this binary. + +As developers may be wary about running on unknown binary on their systems you may find it quicker to do some experiments yourself. If you run qemu under perf for 2.12 and 3.0+ (or current git) that might give some indication about what has changed. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1816805 b/results/classifier/118/x86/1816805 new file mode 100644 index 000000000..f125d35e5 --- /dev/null +++ b/results/classifier/118/x86/1816805 @@ -0,0 +1,54 @@ +x86: 0.881 +device: 0.742 +i386: 0.630 +user-level: 0.589 +graphic: 0.589 +performance: 0.562 +architecture: 0.524 +semantic: 0.507 +VMM: 0.491 +mistranslation: 0.476 +kernel: 0.460 +network: 0.453 +virtual: 0.444 +socket: 0.444 +vnc: 0.432 +risc-v: 0.388 +hypervisor: 0.371 +permissions: 0.369 +register: 0.354 +ppc: 0.341 +peripherals: 0.326 +PID: 0.326 +boot: 0.315 +arm: 0.260 +assembly: 0.232 +files: 0.187 +debug: 0.182 +TCG: 0.144 +KVM: 0.111 + +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. + +Hi, versions 2.5 and 2.11 are quite old (though version 2.10 fixed the bug mentioned in the Red Hat BZ, so I think this might be a different bug.) + + +It's not clear at what step this is failing or where you are seeing the error message, so: + +1. What is your full command line for QEMU? +2. Do you see this error message when migrating? If so, what does the destination QEMU command line look like? +3. Does the problem reproduce on a currently-supported upstream QEMU? (4.1.1, 4.2.0) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1819108 b/results/classifier/118/x86/1819108 new file mode 100644 index 000000000..3e9009048 --- /dev/null +++ b/results/classifier/118/x86/1819108 @@ -0,0 +1,69 @@ +x86: 0.934 +vnc: 0.761 +device: 0.684 +kernel: 0.624 +KVM: 0.601 +PID: 0.547 +architecture: 0.535 +performance: 0.490 +mistranslation: 0.484 +semantic: 0.415 +network: 0.413 +socket: 0.391 +peripherals: 0.379 +user-level: 0.308 +boot: 0.293 +virtual: 0.292 +ppc: 0.288 +graphic: 0.284 +register: 0.265 +hypervisor: 0.255 +files: 0.219 +permissions: 0.211 +debug: 0.198 +VMM: 0.170 +risc-v: 0.131 +TCG: 0.120 +i386: 0.110 +arm: 0.078 +assembly: 0.073 + +qemu-bridge-helper failure but qemu not exit + +When qemu-bridge-helper run failed, its parent process qemu is still alive. +This is my command line: + +qemu-system-x86_64 -curses -enable-kvm -cpu host -smp 4 -m 4096 \ + -vnc :1 \ + -kernel /data/xugang_vms/boot/vmlinuz \ + -initrd /data/xugang_vms/boot/initram \ + -append 'module_blacklist=drm,evbug net.ifnames=0 biosdevname=0 ROOTDEV=rootfs' \ + -drive file=/data/xugang_vms/instances/vn7/rootfs.img,format=qcow2,if=virtio \ + -monitor unix:/data/xugang_vms/var/monitor/vn7.sock,server,nowait \ + -netdev bridge,br=vmbr99,helper="/root/bridgehelper --ns=kvm_1 ",id=n1 -device virtio-net,netdev=n1,mac=92:99:98:76:01:07 + +"/root/bridgehelper" is self defined helper binary by me. But after bridge-helper exited with failure(not send fd to qemu process yet), the linux vm's console will be messed up. I checked the qemu source code(at net/tap.c) and found following snip: + +===> +do { + fd = recv_fd(sv[0]); + } while (fd == -1 && errno == EINTR); + saved_errno = errno; + + close(sv[0]); + + while (waitpid(pid, &status, 0) != pid) { + /* loop */ + } +<========= + +why recv_fd will infinitely wait for recv? Maybe it shall waitpid and then recv_fd ? + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/166 + + diff --git a/results/classifier/118/x86/1828 b/results/classifier/118/x86/1828 new file mode 100644 index 000000000..a22dbc827 --- /dev/null +++ b/results/classifier/118/x86/1828 @@ -0,0 +1,51 @@ +x86: 0.922 +device: 0.840 +graphic: 0.764 +performance: 0.712 +hypervisor: 0.560 +semantic: 0.436 +kernel: 0.430 +i386: 0.409 +PID: 0.372 +risc-v: 0.342 +network: 0.329 +vnc: 0.296 +debug: 0.291 +register: 0.242 +virtual: 0.235 +socket: 0.219 +architecture: 0.217 +VMM: 0.205 +arm: 0.200 +files: 0.190 +permissions: 0.190 +user-level: 0.182 +ppc: 0.158 +KVM: 0.155 +boot: 0.154 +mistranslation: 0.152 +TCG: 0.116 +assembly: 0.104 +peripherals: 0.093 + +[v8.0.4 regression] `qemu-system-x86_64: -accel hvf: Unknown Error` +Description of problem: +`-accel hvf` crashes with "Unknown Error". +Regression in v8.0.4. + +The master branch doesn't seem affected. +Steps to reproduce: +v8.0.3: +```console +$ qemu-system-x86_64 -accel hvf +(shows iPXE screen, as expected) +``` + +v8.0.4: +```console +$ qemu-system-x86_64 -accel hvf +qemu-system-x86_64: -accel hvf: Unknown Error +Abort trap: 6 +``` +Additional information: + diff --git a/results/classifier/118/x86/1828429 b/results/classifier/118/x86/1828429 new file mode 100644 index 000000000..2adfaf29a --- /dev/null +++ b/results/classifier/118/x86/1828429 @@ -0,0 +1,53 @@ +x86: 0.829 +graphic: 0.768 +architecture: 0.714 +kernel: 0.694 +semantic: 0.659 +network: 0.571 +TCG: 0.567 +device: 0.523 +socket: 0.363 +ppc: 0.351 +user-level: 0.305 +performance: 0.296 +register: 0.295 +hypervisor: 0.240 +vnc: 0.230 +peripherals: 0.228 +PID: 0.213 +virtual: 0.202 +boot: 0.199 +files: 0.189 +mistranslation: 0.183 +permissions: 0.172 +i386: 0.162 +arm: 0.158 +debug: 0.149 +risc-v: 0.125 +VMM: 0.099 +assembly: 0.068 +KVM: 0.048 + +qemu-system-aarch64 crashes with assertion failed while running GCC 9 test suite + +I am using QEMU 4.0.0 on an x86_64 Linux 4.19.0 host, the guest is an Aarch64 linux 5.0.0 system. The same issue occurred on QEMU 3.1.0. + +While running the GCC 9.1 test suite on the guest system, QEMU crashes with: + +qemu-system-aarch64: [...]/qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed. + +I am able to reproduce the issue reliably, which is encouraging. The full QEMU command line is: + +qemu-system-aarch64 -kernel kernel-5.0.0cbl1 -append "root=/dev/vda1 ro init=/sbin/init console=ttyAMA0" -name guest=cbl -drive file=cbl.qcow2,index=0,media=disk,format=qcow2 -drive file=swap.qcow2,index=1,media=disk,format=qcow2 -machine virt -cpu cortex-a57 -smp 4,sockets=1,cores=2,threads=2 -m size=8192 -netdev tap,id=network0,ifname=tapcbl2,script=no,downscript=no -device virtio-net-device,netdev=network0,mac=aa:bb:cc:dd:ee:02 -nographic + +The specific GCC test that causes QEMU to crash is vldX.c run from advsimd-intrinsics.exp; I can reproduce via "make check-gcc RUNTESTFLAGS=advsimd-intrinsics.exp=vldX.c" + +If there is anything I can do to further triage the issue, or gain more insight into what is going on, please let me know! I am eager to help however I can. + +Hi -- this looks rather like bug #1824853, which exists in QEMU 4.0 but which we have fixed in git. Could you try with a build of QEMU from current head-of-git to confirm that it's fixed there ? + + +I'm on it. Will follow up when I have a result. + +Confirmed, this is a duplicate of 1824853 and is resolved in 68a7b9724fe80bedb85060bde605213ce3f9baec. + diff --git a/results/classifier/118/x86/1828507 b/results/classifier/118/x86/1828507 new file mode 100644 index 000000000..791fba89a --- /dev/null +++ b/results/classifier/118/x86/1828507 @@ -0,0 +1,95 @@ +x86: 0.808 +register: 0.716 +architecture: 0.697 +ppc: 0.693 +graphic: 0.679 +device: 0.671 +network: 0.600 +boot: 0.561 +semantic: 0.550 +PID: 0.513 +socket: 0.508 +permissions: 0.499 +kernel: 0.474 +performance: 0.459 +assembly: 0.445 +debug: 0.436 +vnc: 0.435 +peripherals: 0.429 +user-level: 0.423 +mistranslation: 0.391 +hypervisor: 0.372 +files: 0.368 +risc-v: 0.343 +VMM: 0.316 +TCG: 0.306 +arm: 0.301 +i386: 0.278 +virtual: 0.238 +KVM: 0.163 + +qemu-system-ppc64 smp crash on manual reset + +Host Environment: + x86_64 Linux v5.0.2 + QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4) + SLOF: + Build Date = Jan 14 2019 18:00:39 + FW Version = git-a5b428e1c1eae703 + +Problem: Qemu crash immediately after a manual reset + (this is not the initial reset which launches the guest). + +Steps: + +1. Download Debian ppc64el mini.iso: + http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso +2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a single CPU, I was unable + to reproduce the crash. + qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso +3. SLOF prints the version info on the serial device, and proceeds to boot. +4. After a few seconds, the GRUB menu appears on the VGA screen. +5. Select one of the install options (I have tested with Default and Expert), and wait + for the Debian's text-mode installer (blue-gray-red) screen to appear. +6. Click Machine->Reset (or enter system_reset on the qemu monitor). +7. Notice that, on the serial device, SLOF has printed the version info. That is, the system + has reset and is attempting to boot again. +8. On the host cmd prompt, qemu dies after printing this fatal error and spewing the + contents of the CPU registers: + + qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support + <CPU contents> (See attached out.txt for details) + Aborted (core dumped) + + +The HV exception is either + (a) 70 = HISI, which occurs when NIP contains an outright bogus or inaccessible value, or + (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner value, and + the cpu attempts to run the instruction at that address. + +The exception can occur on either of the CPUs. It occurs when qemu is running the SLOF +code. + + + +If one continues with the iso, and installs the OS in the +guest, the rebooting of the guest from within the guest +OS too causes qemu to exit fatally. So, one can run +'systemctl reboot' or 'reboot' within the guest OS and +see qemu crash (immediately after SLOF prints version, +etc. as part of the reboot sequence, as described before). + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1836451 b/results/classifier/118/x86/1836451 new file mode 100644 index 000000000..a23829fc0 --- /dev/null +++ b/results/classifier/118/x86/1836451 @@ -0,0 +1,53 @@ +x86: 0.942 +device: 0.891 +graphic: 0.700 +PID: 0.665 +kernel: 0.621 +network: 0.600 +assembly: 0.600 +socket: 0.581 +ppc: 0.550 +TCG: 0.534 +user-level: 0.531 +arm: 0.516 +mistranslation: 0.505 +semantic: 0.498 +files: 0.479 +vnc: 0.462 +VMM: 0.460 +hypervisor: 0.439 +risc-v: 0.435 +boot: 0.419 +architecture: 0.403 +register: 0.397 +performance: 0.388 +debug: 0.362 +virtual: 0.337 +i386: 0.307 +permissions: 0.306 +KVM: 0.260 +peripherals: 0.218 + +'make info' fails due to errors in qemu-tech.texi + +git tag: v4.1.0-rc0 +host: Fedora 29, x86_64 + +$ make info +make[1]: Entering directory 'qemu/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory 'qemu/slirp' + GEN docs/version.texi + GEN qemu-options.texi + GEN qemu-monitor.texi + GEN qemu-img-cmds.texi + GEN qemu-monitor-info.texi + GEN qemu-doc.info +qemu/qemu-tech.texi:6: @menu reference to nonexistent node `Translator Internals' +qemu/qemu-tech.texi:7: @menu reference to nonexistent node `QEMU compared to other emulators' +qemu/qemu-tech.texi:9: @menu reference to nonexistent node `Bibliography' +Makefile:960: recipe for target 'qemu-doc.info' failed +make: *** [qemu-doc.info] Error 1 + +Fixed by commit 32481687e1a262. + diff --git a/results/classifier/118/x86/1838465 b/results/classifier/118/x86/1838465 new file mode 100644 index 000000000..b40c96cd7 --- /dev/null +++ b/results/classifier/118/x86/1838465 @@ -0,0 +1,63 @@ +x86: 0.912 +kernel: 0.871 +device: 0.779 +architecture: 0.726 +boot: 0.718 +performance: 0.691 +graphic: 0.598 +user-level: 0.598 +TCG: 0.555 +ppc: 0.553 +virtual: 0.544 +PID: 0.509 +hypervisor: 0.478 +network: 0.474 +socket: 0.471 +files: 0.469 +mistranslation: 0.456 +permissions: 0.455 +register: 0.423 +peripherals: 0.408 +debug: 0.407 +vnc: 0.405 +arm: 0.342 +semantic: 0.321 +assembly: 0.297 +i386: 0.257 +risc-v: 0.242 +VMM: 0.234 +KVM: 0.184 + +qemu-system-x86_64 kernel panic 30% of the time starting up VM + +I have created a Fedora Core 5 x86_64 VM image. When I run the image using QEMU on Windows the VM hangs while loading the kernel about 30% of the time. I am trying to use this VM with a CI software, looking at the history the build failed 27 out of 79 attempts. QEMU 3.0.0 is installed on the CI machine. I have tried using the exact same image using QEMU on Linux (Ubuntu) and found the image boot successful every time (40+ attempts). The VM image is fairly old it was created using QEMU 0.11.1. + +I have tried multiple versions on QEMU on windows; 0.11.1, 2.12.1, and 3.0.0 all of them fail randomly. I can reproduce the issue on several different Windows 10 computers. + +The command I am using to start the VM is “qemu-system-x86_64.exe -cpu qemu64 -smp cores=2 -device e1000,netdev=net0 -boot menu=off -m 1G -drive `"file=C:\qimages\Fedora-Core-5-x64.qcow2,index=0,media=disk`" -snapshot -netdev user,id=net0,hostfwd=tcp::10022-:22” + +I can provide the qcow image but it is somewhat large coming it at 4.15GB so I’m not sure what would be the best way to transfer it. + + + +Is this using TCG (i.e. emulation) rather than Hyper V virtualisation? + +There are problems reliable booting the VM using TCG, HAXM, and Hyper-V. TCG fails the least often. Attached is a pic of the error using HAXM, a lot of "BUG: soft lockup detect on CPU#x!". + +I tried to add logging but nothing ever shows up in the log file. I tried adding "-d cpu,guest_errors -D E:\log.txt" to the command but the log file is always empty. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1856027 b/results/classifier/118/x86/1856027 new file mode 100644 index 000000000..ddfddf503 --- /dev/null +++ b/results/classifier/118/x86/1856027 @@ -0,0 +1,53 @@ +x86: 0.880 +graphic: 0.865 +device: 0.737 +user-level: 0.709 +network: 0.679 +hypervisor: 0.638 +vnc: 0.587 +semantic: 0.561 +socket: 0.558 +performance: 0.555 +mistranslation: 0.548 +architecture: 0.520 +register: 0.509 +PID: 0.499 +files: 0.491 +i386: 0.487 +permissions: 0.474 +ppc: 0.473 +risc-v: 0.447 +kernel: 0.426 +boot: 0.418 +virtual: 0.400 +peripherals: 0.388 +arm: 0.361 +debug: 0.356 +VMM: 0.347 +assembly: 0.326 +TCG: 0.287 +KVM: 0.251 + +Suddenly no internet in guest system! + +I use Opensuse 15.1 i have installed androidx86_64 as a guest system, it runs for over 3 years. i had a internetconnection, i could use apps etc. but since yesterday i can´t connect to the internet with the guest system in the host system all works fine. What could be the reason? There haven´t been an update and i haven´t changed anything. +The settings in nic are: bridge br0: Hostdevice eth0 +devicemodel: e1000 + +The qemu Version is from the opensuse repo: 3.1.1 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1872644 b/results/classifier/118/x86/1872644 new file mode 100644 index 000000000..cebe7069c --- /dev/null +++ b/results/classifier/118/x86/1872644 @@ -0,0 +1,89 @@ +x86: 0.861 +kernel: 0.805 +performance: 0.791 +architecture: 0.777 +boot: 0.754 +device: 0.728 +peripherals: 0.709 +debug: 0.669 +network: 0.662 +mistranslation: 0.662 +graphic: 0.659 +socket: 0.607 +ppc: 0.599 +files: 0.573 +PID: 0.568 +hypervisor: 0.567 +assembly: 0.555 +risc-v: 0.518 +semantic: 0.499 +arm: 0.496 +user-level: 0.495 +permissions: 0.487 +vnc: 0.431 +register: 0.425 +virtual: 0.393 +VMM: 0.374 +TCG: 0.360 +i386: 0.333 +KVM: 0.238 + +MacOS host qemu-system-x86_64 -cpu host not working + +MacOS: 10.15.4 +uname -a: Linux door 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I am using qemu on mac host, with ubuntu client. + +I used to have "-cpu host" in my qemu command as follow:- + +qemu-system-x86_64 \ +-no-user-config \ +-nodefaults \ +-name u64d01 \ +-show-cursor \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host \ +-m 8192M \ +-smp 4 \ +-rtc base=utc,clock=host \ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=/Users/js/code/vm/qemu/u64d01.qcow2,if=none,format=qcow2 \ +-device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +-device virtio-tablet-pci \ +-device virtio-vga \ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0 + +Base on log of one of the vm, it was definitely working on 2020-01-17(base on journal inside vm), with qemu 4.2.0, which I installed with brew. + +The only way to make it work is to remove "-cpu host". + +Already tried with 4.1.1, 4.2 and 5.0rc2. Same result. + +To reproduce, try above with a Ubuntu 18.04 installation cd. Client will crash during kernel loading. + + + +I found that things were unstable unless the following were also added +-cpu Nehalem,-rdtscp +(the CPU can be higher than Nehalem but obviously your host CPU actually has to be equal or greater too) + +-rdtscp is a known issue that has since been workedaround (see bug #1894836 ). + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1874904 b/results/classifier/118/x86/1874904 new file mode 100644 index 000000000..809e04d84 --- /dev/null +++ b/results/classifier/118/x86/1874904 @@ -0,0 +1,56 @@ +x86: 0.887 +graphic: 0.751 +device: 0.679 +mistranslation: 0.661 +performance: 0.630 +architecture: 0.585 +semantic: 0.567 +network: 0.530 +user-level: 0.516 +permissions: 0.496 +files: 0.486 +debug: 0.466 +PID: 0.458 +arm: 0.442 +boot: 0.436 +i386: 0.432 +ppc: 0.422 +socket: 0.422 +peripherals: 0.419 +register: 0.399 +risc-v: 0.346 +kernel: 0.345 +vnc: 0.333 +hypervisor: 0.255 +VMM: 0.248 +virtual: 0.234 +TCG: 0.217 +assembly: 0.211 +KVM: 0.118 + +qemu windows with gtk and french keypad not working as expected + +When I use qemu on Windows 10 with a French AZERTY keypad with the correct options the emulated system keypad still QWERTY. If we use sdl it works fine the emulated keypad is AZERTY. + +Example of command with ubuntu live cd: +-> qemu-system-x86_64.exe -m 4G ubuntu-18.04.4-desktop-amd64.iso -display gtk -k fr + +NOTES: + - Using the same command on Linux works fine. The emulated keypad is AZERTY. + +Qemu version : 4.2.0 on Windows 10 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1883083 b/results/classifier/118/x86/1883083 new file mode 100644 index 000000000..52521c337 --- /dev/null +++ b/results/classifier/118/x86/1883083 @@ -0,0 +1,82 @@ +x86: 0.888 +virtual: 0.837 +graphic: 0.816 +performance: 0.767 +files: 0.745 +peripherals: 0.730 +device: 0.706 +architecture: 0.700 +permissions: 0.674 +KVM: 0.613 +PID: 0.605 +socket: 0.600 +network: 0.593 +kernel: 0.576 +vnc: 0.575 +register: 0.566 +ppc: 0.565 +hypervisor: 0.561 +semantic: 0.537 +VMM: 0.526 +arm: 0.482 +boot: 0.474 +user-level: 0.469 +assembly: 0.467 +i386: 0.463 +mistranslation: 0.414 +risc-v: 0.391 +debug: 0.372 +TCG: 0.345 + +QEMU: block/vvfat driver issues + +Nathan Huckleberry <email address hidden> has reported following issues in the block/vvfat driver for the virtual VFAT file system image, used to share a host system directory with a guest VM. + +Please note: + -> https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +Virtual VFAT read/write support is available only for (beta) testing purposes. + +Following issues are reproducible with: + + host)$ ./bin/qemu-system-x86_64 -nographic -enable-kvm \ + -drive file=fat:rw:/tmp/var/run/,index=2 -m 2048 /var/lib/libvirt/images/f27vm.qcow2 + + guest)# mount -t vfat /dev/sdb1 /mnt/ + +The attached reproducers (run inside a guest) include: + +1. dir.sh: - directory traversal on the host + - It creates a file under /mnt/yyyy + - Then edits the VFAT directory entry to make it -> /mnt/../y + - The handle_renames_and_mkdirs() routine does not check this new file name + and creates a file outside of the shared directory on the host + +2. dos.sh: hits an assertion failure in vvfat driver + - Creates a deep directory tree like - /mnt/0/1/2/3/4/5/6/../29/30/ + - While updating vvfat commits, driver hits an assertion in + handle_renames_and_mkdirs + ... + } else if (commit->action == ACTION_MKDIR) { + ... + assert(j < s->mapping.next); <== it fails + +3. read.sh: reads past vvfat directory entries + - Creates a file with: echo "x" > /mnt/a + - Reads past VVFAT directory entry structure with + + # head -c 1000000 $MNTDEV | xxd | grep x -A 512 + + - It may disclose some heap addresses. + +4. write.sh: heap buffer overflow + - Creates large number of files as /mnt/file[1..35] + - while syncing directory tree with the host, driver hits an overflow + while doing memmove(3) in array_roll() routine + + + +This ticket has been transferred to QEMU's new bug tracker here: +https://gitlab.com/qemu-project/qemu/-/issues/272 +... thus closing the issue on Launchpad now. + diff --git a/results/classifier/118/x86/1883739 b/results/classifier/118/x86/1883739 new file mode 100644 index 000000000..38522922c --- /dev/null +++ b/results/classifier/118/x86/1883739 @@ -0,0 +1,69 @@ +x86: 0.885 +graphic: 0.826 +files: 0.809 +performance: 0.804 +KVM: 0.786 +hypervisor: 0.770 +peripherals: 0.751 +device: 0.749 +permissions: 0.733 +ppc: 0.731 +kernel: 0.727 +network: 0.709 +assembly: 0.684 +architecture: 0.677 +mistranslation: 0.659 +PID: 0.659 +socket: 0.652 +boot: 0.626 +i386: 0.615 +register: 0.609 +debug: 0.609 +semantic: 0.601 +VMM: 0.600 +risc-v: 0.597 +TCG: 0.596 +arm: 0.593 +vnc: 0.586 +user-level: 0.517 +virtual: 0.267 + +ide_dma_cb: Assertion `prep_size >= 0 && prep_size <= n * 512' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -drive id=disk,file=hda.img,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 +``` + +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 +``` + +To create disk image run: +``` +dd if=/dev/zero of=hda.img bs=1024 count=1024 +``` + + + +ACK. I do not have time to fix this bug at the moment under the belief that it's likely low-priority and only "misbehaving guests" can trigger it. Some advice: + +1. Do not use IDE in production deployments after initial installation, if you can help it. Use a performant virtio solution. + +2. If anyone would like to fix this problem, I will be more than happy to point you to the exact lines of code that cause the problem. I think the fix will be easy, but testing will be time-consuming as it involves understanding error behavior of real hardware that I don't personally have the setup to quickly test or verify. + +From memory: the problem is that ide_dma_cb expects that it was able to prepare at least one sector's worth of scatter-gather list to begin DMA, but it's possible to give malformed SG lists where IDE is unable to process the remainder of a sector in a list. + +It was not clear to me at the time when I first investigated this what a real controller would do if it got an incomplete sector and how it should signal that. + +It was also not clear to me if the sg_prepare function for the pci bmdma controller would ever encounter a situation where further entries in the list might be received "later" and we should "wait" for them. + +If this bug is more dangerous than a self-inflicted DOS, please let me know and I'll re-prioritize. Patches, email and IRC chats welcome. + +--js + diff --git a/results/classifier/118/x86/1893807 b/results/classifier/118/x86/1893807 new file mode 100644 index 000000000..61d635c35 --- /dev/null +++ b/results/classifier/118/x86/1893807 @@ -0,0 +1,76 @@ +x86: 0.928 +debug: 0.915 +files: 0.851 +graphic: 0.845 +device: 0.831 +permissions: 0.820 +vnc: 0.809 +arm: 0.805 +user-level: 0.788 +network: 0.785 +kernel: 0.761 +performance: 0.759 +socket: 0.753 +hypervisor: 0.748 +architecture: 0.746 +risc-v: 0.741 +mistranslation: 0.732 +PID: 0.731 +peripherals: 0.697 +ppc: 0.686 +VMM: 0.667 +register: 0.667 +TCG: 0.661 +boot: 0.652 +semantic: 0.645 +assembly: 0.623 +KVM: 0.613 +i386: 0.567 +virtual: 0.479 + +Crash when launching windows qemu version from WSL2 + +Version: 5.1.0 +Command line from WSL2: +qemu-system-x86_64.exe -hdd /home/jesus/proyectos/RWivOS/bin/RELEASE/image.hdd -m 4G -smp 4 -machine q35 -debugcon stdio + +OS: Windows 10(64 bits) from WSL2 Ubuntu 18.04 + +The error: +ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/block.c:1325:bdrv_open_driver: assertion + failed: (is_power_of_2(bs->bl.request_alignment)) + +The problem i'm seeing when i lauch from wsl2 only occurs when launched with argument -hdd from WSL2, if i launch it from Windows pointing to the WSL path where the file is stored works. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1907061 b/results/classifier/118/x86/1907061 new file mode 100644 index 000000000..f11f79f6c --- /dev/null +++ b/results/classifier/118/x86/1907061 @@ -0,0 +1,78 @@ +x86: 0.930 +performance: 0.873 +graphic: 0.856 +device: 0.744 +architecture: 0.697 +user-level: 0.674 +PID: 0.663 +network: 0.650 +semantic: 0.633 +files: 0.622 +hypervisor: 0.589 +ppc: 0.563 +kernel: 0.563 +register: 0.552 +socket: 0.543 +debug: 0.542 +permissions: 0.523 +assembly: 0.517 +arm: 0.501 +i386: 0.498 +TCG: 0.480 +peripherals: 0.477 +VMM: 0.461 +mistranslation: 0.452 +vnc: 0.451 +risc-v: 0.423 +boot: 0.375 +KVM: 0.359 +virtual: 0.268 + +qemu-system-x86_64 minimizing window causes keyboard input lag globally + +After qemu window is minimized, it causes keyboard lag on the host for all applications, pressed keys will be delayed and very laggy, typing to notepad or any other text extremely slowly appear on the screen, queue is slowly processed. +If qemu window is open back to normal size, keyboard is back to normal, everything is back to normal and stable, this behavior i have been testing since several months of qemu releases, i am reporting a bit late here, not breaking but it seems important and everytime i accidently minimize qemu, i remember it later and take qemu window to normal size back always, i try never minimize it anymore. +This problem does not occur if using -display none +Guest OS doesn't matter for this behavior, result is always same +I am using: +qemu 5.1.0.0 +qemu-system-x86_64w.exe +Windows 10 build 2004 +4K screen dpi scaling set to 150% + +If requested, i can record a video to see the problem clearly, but i think all information i give already clear now. + +Thanks for making quality software, hope all bugs fixed + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/1913619 b/results/classifier/118/x86/1913619 new file mode 100644 index 000000000..eb6dfddcb --- /dev/null +++ b/results/classifier/118/x86/1913619 @@ -0,0 +1,44 @@ +x86: 0.915 +mistranslation: 0.784 +architecture: 0.749 +device: 0.719 +performance: 0.702 +graphic: 0.698 +user-level: 0.689 +semantic: 0.673 +boot: 0.637 +i386: 0.620 +peripherals: 0.592 +KVM: 0.592 +kernel: 0.552 +network: 0.513 +risc-v: 0.505 +ppc: 0.500 +permissions: 0.496 +VMM: 0.457 +hypervisor: 0.445 +arm: 0.437 +virtual: 0.420 +vnc: 0.419 +debug: 0.417 +register: 0.406 +files: 0.403 +socket: 0.398 +TCG: 0.394 +PID: 0.327 +assembly: 0.175 + +qemu-system-x86_64 -cdrom -nographic gives no output + +Running 'sudo qemu-system-x86_64 -m 2048M -cpu host -cdrom github/xvisor-bootable.iso -boot d -enable-kvm' will create a qemu window, boot to a grub prompt and then boot the xvisor binary correctly. + +Once I append -nographic to the command - after the user has selected the grub boot binary, there is no further output. + +I've tried various permutations with qemu options, but to no avail. It would be great to have this working as it will permit scrolling back up into the command history for reference and large data output. + +QEMU emulator version 5.2.50 (v5.2.0-925-g7b09f12773) + +The vga-to-serial redirection activated by -nographics works only for vgabios calls, +not for direct vga hardware access. grub2 uses the vgabios, the linux kernel doesn't. +You can edit the menu entry in grub and add "console=ttyS0" to the linux command line. + diff --git a/results/classifier/118/x86/1916 b/results/classifier/118/x86/1916 new file mode 100644 index 000000000..6b8402737 --- /dev/null +++ b/results/classifier/118/x86/1916 @@ -0,0 +1,58 @@ +x86: 0.899 +device: 0.886 +debug: 0.863 +graphic: 0.841 +ppc: 0.811 +PID: 0.782 +kernel: 0.759 +files: 0.748 +register: 0.733 +vnc: 0.697 +performance: 0.693 +socket: 0.683 +semantic: 0.682 +architecture: 0.669 +permissions: 0.654 +network: 0.651 +risc-v: 0.595 +peripherals: 0.582 +VMM: 0.582 +user-level: 0.544 +arm: 0.537 +TCG: 0.526 +boot: 0.499 +i386: 0.482 +hypervisor: 0.447 +mistranslation: 0.446 +assembly: 0.411 +virtual: 0.324 +KVM: 0.149 + +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/118/x86/1921138 b/results/classifier/118/x86/1921138 new file mode 100644 index 000000000..0b2604d67 --- /dev/null +++ b/results/classifier/118/x86/1921138 @@ -0,0 +1,48 @@ +x86: 0.929 +debug: 0.834 +kernel: 0.829 +device: 0.778 +graphic: 0.747 +architecture: 0.710 +TCG: 0.701 +mistranslation: 0.678 +boot: 0.637 +semantic: 0.624 +PID: 0.605 +register: 0.583 +socket: 0.530 +network: 0.513 +i386: 0.503 +permissions: 0.498 +files: 0.497 +ppc: 0.446 +vnc: 0.410 +arm: 0.389 +virtual: 0.334 +user-level: 0.325 +risc-v: 0.291 +performance: 0.241 +VMM: 0.234 +peripherals: 0.128 +assembly: 0.068 +hypervisor: 0.052 +KVM: 0.016 + +tcg.c:3329: tcg fatal error + +I am currently building my own kernel with bootloader and qemu crashed after I have set an IDT in protected mode and then create a invalid opcode exception with the opcode 0xff. + +My code is here: https://github.com/Luis-Hebendanz/svm_kernel/blob/qemu_crash/svm_kernel/external/bootloader/src/main.rs#L80 + +Build instructions are here: https://github.com/Luis-Hebendanz/svm_kernel/tree/qemu_crash + +A precompiled binary is here: https://cloud.gchq.icu/s/LcjoDWRW2CbxJ5i + +I executed the following command: qemu-system-x86_64 -smp cores=4 -cdrom target/x86_64-os/debug/bootimage-svm_kernel.iso -serial stdio -display none -m 4G + +I am running QEMU emulator version 5.1.0 + +https://<email address hidden>/ + +https://gitlab.com/qemu-project/qemu/-/commit/10b8eb94c0902b58 + diff --git a/results/classifier/118/x86/1926 b/results/classifier/118/x86/1926 new file mode 100644 index 000000000..d63d81b59 --- /dev/null +++ b/results/classifier/118/x86/1926 @@ -0,0 +1,54 @@ +x86: 0.899 +graphic: 0.865 +ppc: 0.832 +device: 0.826 +performance: 0.722 +network: 0.618 +vnc: 0.608 +i386: 0.572 +socket: 0.564 +semantic: 0.479 +files: 0.475 +PID: 0.470 +VMM: 0.468 +arm: 0.443 +register: 0.437 +debug: 0.419 +risc-v: 0.416 +permissions: 0.345 +TCG: 0.334 +boot: 0.333 +peripherals: 0.327 +virtual: 0.316 +architecture: 0.299 +hypervisor: 0.265 +mistranslation: 0.245 +user-level: 0.232 +kernel: 0.186 +KVM: 0.166 +assembly: 0.139 + +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/118/x86/1989 b/results/classifier/118/x86/1989 new file mode 100644 index 000000000..576c9e431 --- /dev/null +++ b/results/classifier/118/x86/1989 @@ -0,0 +1,62 @@ +x86: 0.941 +graphic: 0.851 +architecture: 0.711 +i386: 0.698 +debug: 0.646 +device: 0.639 +vnc: 0.632 +semantic: 0.622 +mistranslation: 0.592 +performance: 0.546 +register: 0.523 +PID: 0.485 +network: 0.454 +permissions: 0.453 +ppc: 0.450 +peripherals: 0.423 +kernel: 0.412 +socket: 0.393 +files: 0.391 +virtual: 0.308 +hypervisor: 0.295 +arm: 0.280 +boot: 0.260 +VMM: 0.246 +assembly: 0.245 +risc-v: 0.245 +TCG: 0.168 +KVM: 0.095 +user-level: 0.081 + +Regression: by default qemu opens both vnc and stdout console +Description of problem: +Running qemu with a vnc display (by default I'm not using the -display option) and -monitor stdio, +it fails because the display also wants the std output (it fails even if a pass the -vnc option). +If I remove the monitor I have both the vnc and the std output console at the same time. +I was able to use `-monitor stdio`, passing `-serial telent:...` +Steps to reproduce: +1. ./configure --enable-slirp --target-list=x86_64-softmmu --disable-user --disable-docs +2. make -j 4 +3. qemu-system-x86_64 ... (without `-display` as shown above) +Additional information: +After bisecting I found the following commit changed the behavior: + +``` +commit 1bec1cc0da497e55c16e2a7b50f94cdb2a02197f +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Tue Sep 5 23:18:08 2023 +0400 + + ui/console: allow to override the default VC + + If a display is backed by a specialized VC, allow to override the + default "vc:80Cx24C". + + As suggested by Paolo, if the display doesn't implement a VC (get_vc() + returns NULL), use a fallback that will use a muxed console on stdio. + + This changes the behaviour of "qemu -display none", to create a muxed + serial/monitor by default (on TTY & not daemonized). + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Thomas Huth <thuth@redhat.com> +``` diff --git a/results/classifier/118/x86/2004 b/results/classifier/118/x86/2004 new file mode 100644 index 000000000..337d0d63d --- /dev/null +++ b/results/classifier/118/x86/2004 @@ -0,0 +1,63 @@ +x86: 0.847 +device: 0.815 +files: 0.783 +mistranslation: 0.679 +ppc: 0.676 +graphic: 0.669 +architecture: 0.648 +semantic: 0.592 +network: 0.583 +PID: 0.566 +performance: 0.558 +TCG: 0.529 +socket: 0.523 +permissions: 0.517 +vnc: 0.503 +VMM: 0.487 +debug: 0.486 +risc-v: 0.466 +register: 0.436 +hypervisor: 0.432 +kernel: 0.403 +boot: 0.377 +arm: 0.348 +virtual: 0.341 +user-level: 0.301 +peripherals: 0.287 +KVM: 0.195 +assembly: 0.160 +i386: 0.113 + +do_guest_openat /proc interposition doesn't work for openat +Description of problem: +For instance, trying with hppa emulated on top of x86: + +``` +$ hppa-linux-gnu-gcc test.c -o test +$ qemu-hppa-static ./test +``` + +One gets the host cpu information: + +``` +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 142 +model name : Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz +[...] +``` + +while we would want to see the guest cpu information, like the test program does when `#if 0` is turned into `#if 1`: + +``` +processor : 0 +cpu family : PA-RISC 1.1e +cpu : PA7300LC (PCX-L2) +capabilities : os32 +model : 9000/778/B160L - Merlin L2 160 QEMU (9000/778/B160L) +``` + +This is because `do_guest_openat` only checks for the path, and does not look at `dirfd`, so it doesn't recognize that `openat(dirfd, "cpuinfo", O_RDONLY)` is actually opening a file in `/proc`. + +We could probably, when `dirfd` is not `AT_FDCWD`, try to `fstat()` it, open `/proc` with `O_DIRECTORY` and `fstat()` that too, and compare their `st_dev` and `st_ino`? diff --git a/results/classifier/118/x86/2064 b/results/classifier/118/x86/2064 new file mode 100644 index 000000000..8fc820b2d --- /dev/null +++ b/results/classifier/118/x86/2064 @@ -0,0 +1,42 @@ +x86: 0.949 +architecture: 0.706 +semantic: 0.619 +device: 0.610 +performance: 0.596 +graphic: 0.580 +files: 0.523 +peripherals: 0.492 +socket: 0.490 +ppc: 0.488 +kernel: 0.458 +hypervisor: 0.456 +mistranslation: 0.448 +permissions: 0.444 +register: 0.434 +debug: 0.428 +i386: 0.419 +risc-v: 0.416 +network: 0.376 +vnc: 0.375 +assembly: 0.368 +TCG: 0.361 +PID: 0.347 +VMM: 0.307 +user-level: 0.306 +boot: 0.298 +virtual: 0.289 +arm: 0.209 +KVM: 0.203 + +QEMU v8.2.0-rc4 and above will not take SMI +Description of problem: +Starting from v8.2.0-rc4, the x86 QEMU system will take SMI from an incorrect starting address. Without any firmware relocation, sending an SMI will move the RIP to 0x8000, instead of the traditional 0x38000. This caused the existing UEFI drivers not functional during SMI relocation step. + +After some investigation, the issue was caused by this commit: https://github.com/qemu/qemu/commit/b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27. There seems to be 2 issues with this change: + +1. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L568C1-L572C6 was updated from calculating `cpu_eip` based on `s->pc` to `s->base.pc_next`. This will cause undetermined behavior. +2. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L2848C1-L2869C67 added the routine of updating `new_pc`, which is later used `tcg_gen_addi_tl`. This will cause the `new_pc` to be populated with undesirable value and thus cause faulting behaviors. +Steps to reproduce: +1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic. +Additional information: +I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location. diff --git a/results/classifier/118/x86/2258 b/results/classifier/118/x86/2258 new file mode 100644 index 000000000..07b3b0b09 --- /dev/null +++ b/results/classifier/118/x86/2258 @@ -0,0 +1,53 @@ +x86: 0.944 +graphic: 0.885 +device: 0.829 +kernel: 0.808 +boot: 0.800 +PID: 0.770 +hypervisor: 0.752 +performance: 0.721 +semantic: 0.683 +debug: 0.661 +architecture: 0.657 +files: 0.633 +socket: 0.627 +vnc: 0.596 +peripherals: 0.590 +permissions: 0.567 +register: 0.558 +risc-v: 0.554 +ppc: 0.553 +network: 0.549 +VMM: 0.502 +TCG: 0.480 +arm: 0.454 +mistranslation: 0.446 +user-level: 0.412 +assembly: 0.382 +i386: 0.381 +virtual: 0.274 +KVM: 0.242 + +Breakpoint setting not working on apple Mac host +Description of problem: +1. When use with parameter "-machine virt,accel=hvf -cpu host" to run launch a emulator, it can't set breakpoint and will report error: "warning: failed to set breakpoint site at 0xffff800081bf03cc for breakpoint 1.1: error: 34 sending the breakpoint request" +but if not use with parameter "-machine virt -cpu cortex-a57"，The breakpoint can be set successfully. + +2. Set hardware breakpoint with lldb command "breakpoint set -H -a 0xFFFF800080000000" not report error, but can't hint breakpoint. I try set breakpoint on a old x86 MacOS, It will hint breakpoint successfully. + +3. I also try run qemu-system-x86_64 emulator on apple silicon mac, It also can't hint hardware breakping. The command is: +``` +qemu-system-x86_64 -machine q35,accel=tcg -smp cpus=8 \ + -kernel arch/x86/boot/bzImage \ + -append "okaslr"\ + -nographic -serial mon:stdio \ + -m 16G \ + -s -S +``` +Steps to reproduce: +1. Launch qemu on Apple silicon Mac. Remember to user "hvf" +2. Launch lldb or gdb to set breakpoint. +3. Set breakpoint and hardware breakpoint. +4. resume to run qemu by lldb. +Additional information: + diff --git a/results/classifier/118/x86/2263 b/results/classifier/118/x86/2263 new file mode 100644 index 000000000..b22621c58 --- /dev/null +++ b/results/classifier/118/x86/2263 @@ -0,0 +1,58 @@ +x86: 0.888 +graphic: 0.883 +performance: 0.797 +debug: 0.796 +device: 0.773 +KVM: 0.764 +architecture: 0.764 +kernel: 0.760 +user-level: 0.740 +semantic: 0.715 +files: 0.677 +hypervisor: 0.674 +boot: 0.647 +socket: 0.637 +register: 0.597 +virtual: 0.548 +peripherals: 0.504 +vnc: 0.494 +PID: 0.480 +ppc: 0.480 +VMM: 0.468 +network: 0.457 +i386: 0.451 +permissions: 0.449 +risc-v: 0.431 +arm: 0.413 +assembly: 0.408 +mistranslation: 0.408 +TCG: 0.328 + +guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0 +Description of problem: +The guest experiences a panic when attempting to perform the `loadvm` operation after it has been running for a while on the x86_64 platform with `kvm_intel ept=0`. I'm unsure if this operation is permitted or not, but it functions properly when using `kvm_intel ept=1`. +Steps to reproduce: +1. Load the `kvm-intel` module with the parameter `ept=0`. +2. savevm +Boot the first guest using the previous command line and switch to the QEMU console to execute the `savevm` operation. After that, proceed to shutting down the guest. +3. loadvm +Boot the second guest using the same command line and switch to the QEMU console to execute the `loadevm` operation. After that, the guest panics. +Additional information: +I have performed some debugging and it seems that the issue lies in the fact that the VMM modifies the guest memory without informing the KVM module. Upon further investigation, I noticed that the `loadvm` operation only restores the memory and does not execute any ioctl to modify the user memory region recorded in the KVM module. + +The KVM module calls `kvm_mmu_reset_context()` to unload the current EPT or SPT page table when guest system registers (CR0/CR3/CR4) are restored. However, for EPT, the EPT page table is released directly and can be reconstructed at a later stage. In contrast, for SPT, the KVM only decreases the reference count and retains the outdated SPT page table in the active list that is maintained by the KVM. As a result, this outdated SPT page table is reused later, leading to incorrect mapping. + +To address this, I attempted to call `kvm_arch_flush_shadow_all()` to zap all the page tables in `kvm_mmu_reset_context()`, which allowed the guest to function properly with SPT after the `loadvm` operation. + +Therefore, I believe that QEMU should notify the KVM to clear all the page tables if the KVM is using shadow paging. However, it appears that there is no appropriate ioctl available for the VMM to achieve this. + +guest panic output: + + +Trace the `kvm_mmu_get_page()` event and observe that only one record indicates that the outdated page table is reused instead of being recreated. + + +```shell +perf record -a -e kvmmmu:kvm_mmu_get_page +``` + diff --git a/results/classifier/118/x86/2295 b/results/classifier/118/x86/2295 new file mode 100644 index 000000000..32de2b302 --- /dev/null +++ b/results/classifier/118/x86/2295 @@ -0,0 +1,34 @@ +x86: 0.970 +device: 0.848 +performance: 0.777 +architecture: 0.773 +graphic: 0.647 +mistranslation: 0.637 +risc-v: 0.604 +arm: 0.453 +boot: 0.397 +ppc: 0.356 +semantic: 0.344 +socket: 0.302 +TCG: 0.272 +kernel: 0.263 +vnc: 0.248 +VMM: 0.209 +PID: 0.186 +register: 0.136 +hypervisor: 0.125 +debug: 0.116 +assembly: 0.078 +network: 0.073 +files: 0.072 +virtual: 0.069 +KVM: 0.060 +i386: 0.058 +peripherals: 0.054 +permissions: 0.026 +user-level: 0.001 + +Support Apple Silicon acceleration for x86 / x86_64 guests +Additional information: +* [Top-level discussion on UTM downstream](https://github.com/utmapp/UTM/issues/5460) +* [Discussion on memory access instructions on UTM downstream](https://github.com/utmapp/UTM/issues/2366) diff --git a/results/classifier/118/x86/2359 b/results/classifier/118/x86/2359 new file mode 100644 index 000000000..34b8b00b0 --- /dev/null +++ b/results/classifier/118/x86/2359 @@ -0,0 +1,62 @@ +x86: 0.937 +device: 0.901 +graphic: 0.756 +hypervisor: 0.737 +virtual: 0.677 +performance: 0.618 +semantic: 0.599 +i386: 0.497 +PID: 0.444 +architecture: 0.432 +socket: 0.413 +debug: 0.412 +ppc: 0.405 +mistranslation: 0.386 +kernel: 0.327 +peripherals: 0.319 +network: 0.309 +vnc: 0.302 +register: 0.294 +VMM: 0.251 +user-level: 0.208 +TCG: 0.192 +risc-v: 0.188 +assembly: 0.183 +arm: 0.170 +KVM: 0.148 +permissions: 0.148 +files: 0.119 +boot: 0.114 + +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/118/x86/237 b/results/classifier/118/x86/237 new file mode 100644 index 000000000..d0af1d329 --- /dev/null +++ b/results/classifier/118/x86/237 @@ -0,0 +1,31 @@ +x86: 0.959 +user-level: 0.631 +device: 0.503 +arm: 0.435 +performance: 0.387 +mistranslation: 0.375 +permissions: 0.269 +boot: 0.249 +semantic: 0.234 +architecture: 0.207 +graphic: 0.204 +debug: 0.202 +register: 0.171 +risc-v: 0.159 +network: 0.157 +kernel: 0.152 +peripherals: 0.134 +hypervisor: 0.122 +socket: 0.116 +assembly: 0.070 +i386: 0.067 +files: 0.052 +VMM: 0.051 +PID: 0.050 +vnc: 0.048 +TCG: 0.044 +ppc: 0.040 +KVM: 0.013 +virtual: 0.010 + +[Feature request] x86: dump MSR features in human form diff --git a/results/classifier/118/x86/2388 b/results/classifier/118/x86/2388 new file mode 100644 index 000000000..e54ac8a8d --- /dev/null +++ b/results/classifier/118/x86/2388 @@ -0,0 +1,47 @@ +x86: 0.938 +graphic: 0.784 +device: 0.653 +i386: 0.567 +semantic: 0.477 +performance: 0.415 +files: 0.408 +architecture: 0.347 +boot: 0.312 +vnc: 0.306 +virtual: 0.250 +mistranslation: 0.236 +user-level: 0.225 +kernel: 0.215 +register: 0.197 +socket: 0.188 +permissions: 0.165 +PID: 0.162 +network: 0.152 +hypervisor: 0.096 +risc-v: 0.069 +ppc: 0.069 +debug: 0.068 +TCG: 0.034 +VMM: 0.033 +arm: 0.032 +peripherals: 0.029 +assembly: 0.022 +KVM: 0.006 + +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/118/x86/2545 b/results/classifier/118/x86/2545 new file mode 100644 index 000000000..39d6beb95 --- /dev/null +++ b/results/classifier/118/x86/2545 @@ -0,0 +1,39 @@ +x86: 0.927 +device: 0.864 +performance: 0.769 +architecture: 0.767 +network: 0.630 +debug: 0.614 +files: 0.606 +arm: 0.605 +register: 0.563 +graphic: 0.533 +boot: 0.511 +socket: 0.499 +permissions: 0.456 +vnc: 0.422 +hypervisor: 0.400 +semantic: 0.336 +kernel: 0.324 +PID: 0.310 +peripherals: 0.282 +risc-v: 0.269 +mistranslation: 0.247 +VMM: 0.235 +TCG: 0.209 +user-level: 0.169 +ppc: 0.128 +virtual: 0.125 +i386: 0.117 +assembly: 0.095 +KVM: 0.033 + +QEMU Version 9.0.0 - HAXM 7.8.0.0 - Error : qemu-system-x86_64.exe: -accel hax: invalid accelerator hax +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/x86/2599 b/results/classifier/118/x86/2599 new file mode 100644 index 000000000..1b2992c98 --- /dev/null +++ b/results/classifier/118/x86/2599 @@ -0,0 +1,31 @@ +x86: 0.990 +architecture: 0.795 +mistranslation: 0.782 +device: 0.660 +performance: 0.635 +graphic: 0.554 +peripherals: 0.468 +virtual: 0.400 +arm: 0.348 +network: 0.313 +debug: 0.239 +assembly: 0.229 +risc-v: 0.216 +permissions: 0.212 +files: 0.185 +semantic: 0.177 +i386: 0.169 +hypervisor: 0.142 +register: 0.138 +ppc: 0.134 +vnc: 0.126 +boot: 0.124 +TCG: 0.083 +VMM: 0.075 +kernel: 0.070 +user-level: 0.070 +socket: 0.068 +PID: 0.065 +KVM: 0.060 + +[x86] RET imm16 not align with native machine diff --git a/results/classifier/118/x86/2628 b/results/classifier/118/x86/2628 new file mode 100644 index 000000000..d13d245ec --- /dev/null +++ b/results/classifier/118/x86/2628 @@ -0,0 +1,50 @@ +x86: 0.971 +arm: 0.842 +device: 0.823 +PID: 0.821 +user-level: 0.779 +graphic: 0.766 +architecture: 0.749 +semantic: 0.746 +permissions: 0.739 +register: 0.732 +ppc: 0.695 +TCG: 0.694 +risc-v: 0.693 +VMM: 0.673 +socket: 0.669 +vnc: 0.661 +boot: 0.634 +files: 0.604 +performance: 0.595 +mistranslation: 0.544 +network: 0.518 +debug: 0.465 +kernel: 0.447 +virtual: 0.380 +peripherals: 0.251 +assembly: 0.227 +hypervisor: 0.157 +KVM: 0.057 +i386: 0.035 + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines +Description of problem: +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version + +dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped +Steps to reproduce: +1. debootstrap --arch=arm64 stable /scratch/debian-stable +2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version +Additional information: +Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU + +chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes diff --git a/results/classifier/118/x86/2633 b/results/classifier/118/x86/2633 new file mode 100644 index 000000000..9391f0c37 --- /dev/null +++ b/results/classifier/118/x86/2633 @@ -0,0 +1,56 @@ +x86: 0.884 +graphic: 0.864 +peripherals: 0.824 +device: 0.812 +performance: 0.796 +PID: 0.787 +KVM: 0.769 +architecture: 0.761 +debug: 0.745 +semantic: 0.741 +risc-v: 0.740 +socket: 0.732 +register: 0.730 +VMM: 0.724 +network: 0.716 +hypervisor: 0.713 +kernel: 0.685 +vnc: 0.677 +files: 0.676 +arm: 0.670 +permissions: 0.664 +TCG: 0.655 +ppc: 0.651 +mistranslation: 0.603 +assembly: 0.592 +boot: 0.581 +i386: 0.579 +virtual: 0.573 +user-level: 0.526 + +migration-test occassionally hangs with "Failed to peek at channel" +Description of problem: +Running the 'migration-test' qtest in a loop, eventually resulted in a hang. + +``` +# Running /x86_64/migration/multifd/tcp/plain/cancel +# Using machine type: pc-q35-9.2 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name source,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/src_serial -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name target,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# Using machine type: pc-q35-9.2 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name target,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +qemu-system-x86_64: Failed to peek at channel +....hang here.... +``` +Steps to reproduce: +In host run + +``` +make vm-build-openbsd DEBUG=1' +``` +when it is done and gives a shell account then run + +1. `cd /home/qemu/qemu-test.*/build` +2. `export QTEST_QEMU_BINARY=./qemu-system-x86_64` +3. `while true ; do ./tests/qtest/migration-test ; done` +4. ....wait some time until it shows the above hang.... diff --git a/results/classifier/118/x86/265 b/results/classifier/118/x86/265 new file mode 100644 index 000000000..a219eff07 --- /dev/null +++ b/results/classifier/118/x86/265 @@ -0,0 +1,31 @@ +x86: 0.998 +device: 0.793 +kernel: 0.720 +arm: 0.609 +network: 0.591 +mistranslation: 0.584 +risc-v: 0.569 +architecture: 0.514 +VMM: 0.514 +performance: 0.474 +graphic: 0.416 +boot: 0.401 +register: 0.391 +TCG: 0.371 +debug: 0.310 +PID: 0.288 +files: 0.258 +semantic: 0.255 +vnc: 0.237 +assembly: 0.199 +i386: 0.185 +socket: 0.176 +ppc: 0.156 +permissions: 0.151 +peripherals: 0.115 +hypervisor: 0.093 +user-level: 0.073 +KVM: 0.049 +virtual: 0.008 + +x86: retf or iret pagefault sets wrong error code diff --git a/results/classifier/118/x86/2727 b/results/classifier/118/x86/2727 new file mode 100644 index 000000000..035655414 --- /dev/null +++ b/results/classifier/118/x86/2727 @@ -0,0 +1,31 @@ +x86: 0.986 +virtual: 0.911 +network: 0.890 +device: 0.802 +architecture: 0.584 +debug: 0.529 +vnc: 0.496 +graphic: 0.455 +hypervisor: 0.400 +boot: 0.368 +peripherals: 0.361 +PID: 0.353 +semantic: 0.262 +VMM: 0.256 +socket: 0.222 +register: 0.214 +mistranslation: 0.189 +i386: 0.186 +files: 0.162 +TCG: 0.150 +ppc: 0.144 +performance: 0.139 +arm: 0.135 +kernel: 0.132 +risc-v: 0.094 +user-level: 0.094 +assembly: 0.066 +permissions: 0.032 +KVM: 0.008 + +`Debian testing` (2024-12-16) - `qemu-system-x86_64 9.2.0` : bug with the `virtio-net` and a DHCP connection with a virtual bridge. diff --git a/results/classifier/118/x86/2738 b/results/classifier/118/x86/2738 new file mode 100644 index 000000000..f6622a96f --- /dev/null +++ b/results/classifier/118/x86/2738 @@ -0,0 +1,40 @@ +x86: 0.953 +graphic: 0.912 +device: 0.818 +architecture: 0.780 +PID: 0.539 +files: 0.515 +performance: 0.511 +network: 0.394 +register: 0.384 +vnc: 0.344 +debug: 0.339 +boot: 0.315 +semantic: 0.284 +permissions: 0.276 +ppc: 0.257 +TCG: 0.245 +mistranslation: 0.224 +socket: 0.222 +arm: 0.169 +user-level: 0.145 +VMM: 0.134 +kernel: 0.133 +hypervisor: 0.125 +risc-v: 0.114 +peripherals: 0.109 +virtual: 0.082 +KVM: 0.020 +assembly: 0.018 +i386: 0.011 + +golang 1.23 build hangs when running under qemu-user on x86_64 host +Description of problem: +Forwarded from https://github.com/golang/go/issues/70329. + +# +Steps to reproduce: +1. Setup qemu-user binfmt for a foreign ISA, for example, installs qemu-user-static-aarch64 on Fedora. +2. Build the Dockerfile for specified arch: `podman build --arch aarch64 .` +Additional information: + diff --git a/results/classifier/118/x86/2771 b/results/classifier/118/x86/2771 new file mode 100644 index 000000000..74c4a1198 --- /dev/null +++ b/results/classifier/118/x86/2771 @@ -0,0 +1,31 @@ +x86: 0.960 +architecture: 0.762 +kernel: 0.582 +device: 0.564 +performance: 0.493 +debug: 0.428 +mistranslation: 0.419 +graphic: 0.401 +PID: 0.316 +assembly: 0.287 +files: 0.245 +semantic: 0.243 +arm: 0.232 +vnc: 0.228 +network: 0.211 +permissions: 0.179 +socket: 0.160 +register: 0.155 +TCG: 0.151 +ppc: 0.136 +virtual: 0.134 +boot: 0.124 +VMM: 0.122 +KVM: 0.063 +hypervisor: 0.046 +risc-v: 0.039 +peripherals: 0.029 +user-level: 0.015 +i386: 0.007 + +qemu-system-x86_64: ../block/block-backend.c:1290: blk_in_drain: Assertion `qemu_in_main_thread()' failed. diff --git a/results/classifier/118/x86/2834 b/results/classifier/118/x86/2834 new file mode 100644 index 000000000..6da3c1caf --- /dev/null +++ b/results/classifier/118/x86/2834 @@ -0,0 +1,49 @@ +x86: 0.966 +graphic: 0.912 +device: 0.846 +performance: 0.782 +ppc: 0.761 +PID: 0.683 +kernel: 0.668 +vnc: 0.628 +debug: 0.536 +architecture: 0.517 +peripherals: 0.500 +hypervisor: 0.498 +semantic: 0.468 +virtual: 0.447 +register: 0.444 +network: 0.444 +socket: 0.422 +i386: 0.377 +assembly: 0.349 +KVM: 0.345 +boot: 0.339 +VMM: 0.317 +files: 0.257 +mistranslation: 0.231 +permissions: 0.231 +risc-v: 0.176 +user-level: 0.151 +TCG: 0.149 +arm: 0.074 + +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] +Description of problem: +when run `./qemu-system-x86_64 -cpu host,intel_pt -m 8192M -smp 4 -hda ubuntu.qcow2 --enable-kvm --nographic` warning `qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]`. +Tried adding level/min-level=0x14, but still received a warning. +Steps to reproduce: +run command +``` +./qemu-system-x86_64 -cpu host,intel_pt -m 8192M -smp 4 -hda ubuntu.qcow2 --enable-kvm --nographic +``` +Additional information: +- CPU i5-13600kf +``` +~$ sudo rdmsr 0x485 -f 14:14 # MSR_IA32_VMX_MISC_INTEL_PT +1 +~$ sudo rdmsr 0x48B -f 56:56 # SECONDARY_EXEC_PT_USE_GPA +1 +~$ sudo rdmsr 0x484 -f 50:50 # VM_ENTRY_LOAD_IA32_RTIT_CTL +1 +``` diff --git a/results/classifier/118/x86/2922 b/results/classifier/118/x86/2922 new file mode 100644 index 000000000..38d46ec1a --- /dev/null +++ b/results/classifier/118/x86/2922 @@ -0,0 +1,37 @@ +x86: 0.997 +device: 0.835 +architecture: 0.779 +debug: 0.751 +performance: 0.743 +vnc: 0.733 +files: 0.650 +graphic: 0.633 +permissions: 0.518 +PID: 0.484 +mistranslation: 0.439 +register: 0.412 +ppc: 0.401 +VMM: 0.389 +semantic: 0.381 +TCG: 0.363 +risc-v: 0.355 +boot: 0.351 +socket: 0.143 +kernel: 0.137 +virtual: 0.123 +network: 0.122 +arm: 0.111 +user-level: 0.109 +KVM: 0.053 +assembly: 0.039 +peripherals: 0.036 +hypervisor: 0.031 +i386: 0.010 + +x86 reverse-debugging test is unreliable +Description of problem: +The reverse-debugging test for the x86 target is not working reliably. If the host system is under load, the test simply hangs and finally times out. +Steps to reproduce: +1. ``make check-venv`` +2. Run something in the background that keeps all CPUs busy +3. ``for ((x=0;x<10;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_pc ; done`` diff --git a/results/classifier/118/x86/2943 b/results/classifier/118/x86/2943 new file mode 100644 index 000000000..697b27000 --- /dev/null +++ b/results/classifier/118/x86/2943 @@ -0,0 +1,37 @@ +x86: 0.932 +architecture: 0.795 +device: 0.733 +KVM: 0.715 +graphic: 0.698 +vnc: 0.635 +semantic: 0.581 +i386: 0.576 +risc-v: 0.567 +user-level: 0.556 +TCG: 0.545 +register: 0.543 +performance: 0.527 +PID: 0.497 +socket: 0.468 +network: 0.468 +VMM: 0.467 +ppc: 0.452 +mistranslation: 0.416 +boot: 0.412 +files: 0.394 +arm: 0.362 +hypervisor: 0.355 +permissions: 0.351 +debug: 0.317 +kernel: 0.259 +virtual: 0.212 +peripherals: 0.177 +assembly: 0.159 + +Please add a configurable for disabling, or by default disable, KVM_X86_QUIRK_IGNORE_GUEST_PAT on Intel host CPU +Additional information: +I am not familiar with QEMU code base or much programming in general. I did a quick grep through the latest QEMU sources pulled from this repository for the string `KVM_X86_QUIRK_IGNORE_GUEST_PAT`. It does not seem to occur anywhere which makes me think its existence and effect on QEMU users has gone unnoticed. + +If there is a handling of this flag which I have not noticed in the QEMU source code or documentation please guide me to where I can read about and probably configure it. + +Thank you. diff --git a/results/classifier/118/x86/2958 b/results/classifier/118/x86/2958 new file mode 100644 index 000000000..cce1bb905 --- /dev/null +++ b/results/classifier/118/x86/2958 @@ -0,0 +1,48 @@ +x86: 0.922 +graphic: 0.862 +device: 0.856 +files: 0.814 +socket: 0.806 +mistranslation: 0.799 +network: 0.747 +PID: 0.650 +semantic: 0.610 +performance: 0.536 +architecture: 0.517 +ppc: 0.510 +register: 0.467 +debug: 0.445 +arm: 0.442 +risc-v: 0.438 +permissions: 0.416 +virtual: 0.298 +boot: 0.273 +TCG: 0.256 +user-level: 0.244 +i386: 0.241 +vnc: 0.230 +VMM: 0.216 +kernel: 0.194 +peripherals: 0.183 +hypervisor: 0.162 +assembly: 0.076 +KVM: 0.053 + +Vvfat crashes in WinXP-64 installation. +Description of problem: + +Steps to reproduce: +1. Download ISO (see above) +2. Set up qemu +3. Run command above + +Termux output: +qemu-system-x86_64: Slirp: Failed to send packet, ret: -1 [repeated] + +../block/vvfat.c:105: void *array_get(array_t *, unsigned int): assertion "index < array->next" failed +Aborted +~ $ +Additional information: +This was extremely annoying because the total abort occurs far into the installation, while setting up the network. The devices (presumably including the vvfat) had been installed OK. The XP installation can be restarted without the CD but starts at the beginning, needing location, passwords, licence key etc. all over again! I have XP64 installed now, without vvfat which is a marvellously convenient way of transferring files. + +BTW "vfat" usually means extended FAT, handling files over 4GB but vvfat does not. Can you fix that? diff --git a/results/classifier/118/x86/2978 b/results/classifier/118/x86/2978 new file mode 100644 index 000000000..9101ad5b1 --- /dev/null +++ b/results/classifier/118/x86/2978 @@ -0,0 +1,53 @@ +x86: 0.921 +graphic: 0.816 +boot: 0.774 +debug: 0.765 +device: 0.743 +performance: 0.703 +ppc: 0.696 +files: 0.649 +semantic: 0.625 +PID: 0.563 +vnc: 0.492 +architecture: 0.490 +network: 0.483 +socket: 0.481 +kernel: 0.480 +permissions: 0.430 +risc-v: 0.391 +register: 0.387 +i386: 0.370 +virtual: 0.367 +arm: 0.346 +peripherals: 0.326 +mistranslation: 0.304 +TCG: 0.303 +VMM: 0.300 +user-level: 0.246 +hypervisor: 0.238 +KVM: 0.229 +assembly: 0.102 + +Qemu assertion issue +Description of problem: +This issue is **not caused by my OS**, as it runs perfectly under VMware and other emulators. + +However, when using QEMU, the emulator sometimes randomly **crashes or aborts** during boot or early execution. The crash is **inconsistent** — sometimes it runs, sometimes it fails immediately. + +QEMU fails with an **assertion failure** in `qemu_mutex_lock_iothread_impl` +Steps to reproduce: +Unfortunately, I do not know exactly what causes this issue. It may be specific to my system or configuration. + +1. +2. +Additional information: +Qemu stdout: + +``` +ERROR:system/cpus.c:504:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) Bail out! ERROR:system/cpus.c:504:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) ./run: line 3: 3544 Aborted (core dumped) +``` + +Command line: +``` + qemu-system-x86_64 -debugcon file:OxizeOS.log -drive file=output/OxizeOS.hdd,format=raw -serial stdio +``` diff --git a/results/classifier/118/x86/456 b/results/classifier/118/x86/456 new file mode 100644 index 000000000..d5476a631 --- /dev/null +++ b/results/classifier/118/x86/456 @@ -0,0 +1,59 @@ +x86: 0.828 +graphic: 0.729 +files: 0.719 +device: 0.696 +PID: 0.694 +user-level: 0.693 +semantic: 0.674 +performance: 0.655 +architecture: 0.654 +debug: 0.634 +network: 0.425 +peripherals: 0.412 +permissions: 0.408 +kernel: 0.407 +hypervisor: 0.398 +socket: 0.358 +vnc: 0.355 +mistranslation: 0.346 +ppc: 0.328 +register: 0.315 +VMM: 0.308 +virtual: 0.286 +boot: 0.278 +risc-v: 0.264 +arm: 0.263 +TCG: 0.172 +i386: 0.143 +assembly: 0.121 +KVM: 0.101 + +Qemu User (x86_64) Hangs after futex function not implemented error +Description of problem: +Qemu User hangs on futex call with the following last strace +``` +futex(0x0000004001a01654,FUTEX_PRIVATE_FLAG|FUTEX_UNLOCK_PI,0,NULL,NULL,0) = -1 errno=38 (Function not implemented) +``` +This is the last call until giving a SIGINT with CTRL + C where the following strace is output +``` +futex(0x00000040b0085180,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,2,NULL,NULL,0) = -1 errno=4 (Interrupted system call) +--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL, si_pid=0, si_uid=0} --- + +``` +Steps to reproduce: +1. Install steamcmd https://developer.valvesoftware.com/wiki/SteamCMD +2. In the steamcmd shell install Valheim dedicated server with `app_update 896660` +3. Navigate to the downloaded app `cd ~/Steam/steamapps/common/Valheim\ dedicated\ server/` +4. Run `qemu-x86_64 valheim_server.x86_64` +5. The process hangs as per description. +Additional information: +The issue was originally encountered on a raspberry pi ARM64 host using the ubuntu 5.2.0 version of qemu. Installed cross libararies: +* libc6-amd64-cross +* libgcc-s1-amd64-cross + +It was then replicated on the x86 host fedora with a build of the qemu master branch. +The full qemu -strace output is provided below +[qemu_strace_output.log](/uploads/96e0e31b1e63191a94d73f05023c5173/qemu_strace_output.log) + +The expected output found when running `strace ./valheim_server.x86_64` without qemu on the x86_64 host is attached below +[expected_output.log](/uploads/b3b25618103de8a3b9c0ef227bbffc9c/expected_output.log) diff --git a/results/classifier/118/x86/476 b/results/classifier/118/x86/476 new file mode 100644 index 000000000..9be9403fa --- /dev/null +++ b/results/classifier/118/x86/476 @@ -0,0 +1,31 @@ +x86: 0.969 +device: 0.862 +graphic: 0.639 +performance: 0.555 +architecture: 0.546 +arm: 0.340 +network: 0.271 +semantic: 0.240 +virtual: 0.234 +mistranslation: 0.202 +boot: 0.201 +peripherals: 0.194 +files: 0.180 +debug: 0.165 +permissions: 0.160 +PID: 0.156 +risc-v: 0.145 +kernel: 0.127 +hypervisor: 0.103 +register: 0.097 +ppc: 0.096 +user-level: 0.094 +socket: 0.087 +vnc: 0.074 +VMM: 0.034 +assembly: 0.030 +TCG: 0.029 +i386: 0.007 +KVM: 0.001 + +QEMU with x86-64 EFI disk image and 'nographic' option crashes WSL2 window diff --git a/results/classifier/118/x86/492 b/results/classifier/118/x86/492 new file mode 100644 index 000000000..9be3f534d --- /dev/null +++ b/results/classifier/118/x86/492 @@ -0,0 +1,57 @@ +x86: 0.820 +virtual: 0.805 +graphic: 0.771 +semantic: 0.708 +device: 0.673 +hypervisor: 0.671 +performance: 0.631 +PID: 0.619 +debug: 0.602 +files: 0.569 +ppc: 0.565 +VMM: 0.550 +vnc: 0.548 +socket: 0.546 +kernel: 0.534 +network: 0.519 +architecture: 0.505 +arm: 0.471 +peripherals: 0.470 +i386: 0.436 +permissions: 0.422 +mistranslation: 0.419 +risc-v: 0.417 +register: 0.409 +TCG: 0.382 +KVM: 0.380 +boot: 0.367 +user-level: 0.256 +assembly: 0.230 + +[git] "qemu-system-x86_64: Parameter 'drive' is missing" when I tried to launch an existing VM in Virt-Manager. +Description of problem: +This bug is related in some way to bug #488. + +I cannot start an existing virtual machine using qemu-git. +Additional information: +``` +internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing + +``` + +My last working build was made using commit 9bef7ea9. Using Peter Maydell commits as milestone, I noticed commit 9aef0954 was the first showing the bug. + +I'll try to do bisect between these two commits and report asap. There is about 40 commits to verify. diff --git a/results/classifier/118/x86/642304 b/results/classifier/118/x86/642304 new file mode 100644 index 000000000..945b2b253 --- /dev/null +++ b/results/classifier/118/x86/642304 @@ -0,0 +1,76 @@ +x86: 0.863 +KVM: 0.834 +architecture: 0.705 +graphic: 0.688 +user-level: 0.684 +PID: 0.665 +mistranslation: 0.654 +device: 0.632 +semantic: 0.595 +ppc: 0.545 +hypervisor: 0.538 +kernel: 0.529 +virtual: 0.528 +performance: 0.496 +boot: 0.463 +permissions: 0.418 +register: 0.373 +vnc: 0.348 +VMM: 0.343 +socket: 0.322 +TCG: 0.313 +network: 0.309 +risc-v: 0.289 +assembly: 0.275 +debug: 0.242 +arm: 0.213 +files: 0.211 +i386: 0.211 +peripherals: 0.206 + +Solaris/x86 v10 hangs under KVM + +Solaris/x86 10 guest hangs when running under KVM with the message "Running Configuration Assistant". It runs fine when -enable-kvm isn't given as a command option. + +Host OS: Linux/x86_64 +Guest OS: Solaris/x86 +Command Line: qemu -hda solaris.img -m 192 -boot c -enable-kvm +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: 58aebb946acff82c62383f350cab593e55cc13dc + +Your bug report doesn't tell us anything about the host system (AMD, Intel, which CPU model etc), +nor which version of KVM you are running, which distro etc? + +Did it work with older versions of qemu-kvm? + +Which version of Solaris/x86 (pointer to version preferably) + +Please provide appropriate information if you want a chance that anyone will look at this. + +Jes + + +1) Host CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz +2) KVM doesn't have specific "versions" on Debian. The kernel is built with KVM included. The kernel is version 2.6.32-5 +3) Debian 5.0 +4) No - it's never worked for me, but I've only just got around to posting the bug +5) 10 + + + +As I mentioned in email reply, _every_ package in almost every distribution (the ones I know anyway), Debian included, has a version number attached. + +The git commit ID (58aebb946acff82c62383f350cab593e55cc13dc) appears to be in qemu or qemu-kvm git tree (it's found on both), somewhere past 0.13.0-rc0 (dated Sep 18 2010). But from this commit ID it's impossible to tell if you're using qemu or qemu-kvm. + +What are you using --enable-io-thread for? + + + + + +1: If you can give instructions on how to get a version number for kvm on Debian I'll follow them. "dpkg -l | fgrep kvm" lists nothing. +2: I'm using the qemu git tree. +3: Why are you asking? Are you saying that enable-io-thread is broken with --enable-kvm? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/688052 b/results/classifier/118/x86/688052 new file mode 100644 index 000000000..19d4b8ca3 --- /dev/null +++ b/results/classifier/118/x86/688052 @@ -0,0 +1,75 @@ +x86: 0.881 +peripherals: 0.737 +boot: 0.664 +KVM: 0.647 +performance: 0.628 +device: 0.618 +architecture: 0.602 +kernel: 0.577 +ppc: 0.575 +user-level: 0.566 +mistranslation: 0.559 +PID: 0.547 +semantic: 0.532 +network: 0.523 +arm: 0.518 +socket: 0.476 +TCG: 0.462 +i386: 0.452 +graphic: 0.450 +files: 0.425 +virtual: 0.417 +VMM: 0.387 +permissions: 0.387 +vnc: 0.387 +debug: 0.373 +register: 0.367 +hypervisor: 0.328 +risc-v: 0.295 +assembly: 0.218 + +usb does not work 0.13.0 + +Hi all, I'm using both, debian lenny and debian squeeze. +I installed qemu-kvm (0.12.5) form debian repository but I got problem trying to pass a host usb device to the guest. + +I compiled so the latest stable version (0.13.0) hoping that the problem was fixed. +It didn't help, the error I get is always: + +usb_create: no bus specified, using "usb.0" for "usb-host" + +The command I use is + +qemu-system-x86_64 -hda lenny_amd64_vergine.qcow2 -usbdevice host:002.007 -boot order=c + +On internet I found this, it might help: +http://<email address hidden>/msg38795.html + +The guest is a simple debian lenny with 2.6.26 kernel. + + +I tried also to download the qemu development version but the download get interruped + +git clone http://git.qemu.org/qemu.git +Cloning into qemu... +error: Failed connect to git.qemu.org:80; No such file or directory (curl_result = 7, http_code = 0, sha1 = 62d76a25fe741bdaf1157f0edaf50a7772541db6) +error: Unable to find 62d76a25fe741bdaf1157f0edaf50a7772541db6 under http://git.qemu.org/qemu.git + +I attach more info about the host machine I'm testing on. + + + +Thanks for the report. + +For the second part, you need to clone using the git protocol (git clone git://git.qemu.org/qemu.git +as shown in http://wiki.qemu.org/Download#Latest_Source_Code). The http bit appears broken for now. + +I'm not sure about the first part yet - certainly trying a more recent release would be useful to know. + +the correct syntax is +-usb -device usb-host,vendorid=x,productid=y + +at leats on my app-emulation/qemu-kvm-1.0-r2 + +QEMU 0.13.0 is quite outdated - and I assume that USB passthrough should be working fine with the latest version, so I'm closing this bug ticket now. If you still have problems with the latest version of QEMU, feel free to open it again (or create a new bug ticket instead). + diff --git a/results/classifier/118/x86/744856 b/results/classifier/118/x86/744856 new file mode 100644 index 000000000..6487d0bcc --- /dev/null +++ b/results/classifier/118/x86/744856 @@ -0,0 +1,45 @@ +x86: 0.983 +boot: 0.893 +KVM: 0.853 +performance: 0.838 +device: 0.826 +kernel: 0.731 +permissions: 0.719 +graphic: 0.669 +files: 0.626 +i386: 0.624 +vnc: 0.615 +hypervisor: 0.599 +mistranslation: 0.547 +PID: 0.546 +architecture: 0.518 +semantic: 0.502 +peripherals: 0.489 +ppc: 0.482 +user-level: 0.458 +virtual: 0.427 +network: 0.324 +debug: 0.317 +socket: 0.294 +register: 0.260 +risc-v: 0.224 +assembly: 0.202 +VMM: 0.189 +TCG: 0.140 +arm: 0.128 + +can't boot when using more than 6 disks since qemu-kvm-0.13 + +It's not possible to pass more than 6 disks to a guest since qemu-kvm-0.13 (also tested with 0.14). +If I pass more than 6 disks (as shown below) the machine complains that their is no bootable disk, + +The problem occurs with virtio and without virtio. + +eg. + +/usr/bin/qemu-system-x86_64 --enable-kvm -boot c -drive file=/dev/vgr5/fs-01,if=virtio -drive file=/dev/vgr5/fs-01_srv_workspace,if=virtio -drive file=/dev/vgr5/fs-01_srv_media,if=virtio -drive file=/dev/vgr5/fs-01_srv_company,if=virtio -drive file=/dev/vgr5/fs-01_srv_tmp,if=virtio -drive file=/dev/vgr5/fs-01_srv_download,if=virtio -drive file=/dev/vgr5/fs-01_srv_share,if=virtio -drive file=/dev/vgr5/fs-01_srv_backup,if=virtio -drive file=/dev/vgr5/fs-01_srv_private,if=virtio -drive file=/dev/vgr5/fs-01_srv_build,if=virtio -drive file=/dev/vgr5/fs-01_srv_dev,if=virtio -drive file=/dev/vgr5/fs-01_srv_backup2,if=virtio -drive file=/dev/vgr5/fs-01_srv_ftp,if=virtio -cpu qemu64 -smp 2 -m 4G -append root=/dev/vda -usbdevice tablet -net nic,macaddr=90:e6:ba:9d:00:0,model=e1000 -net tap,ifname=tap0,script=/usr/sbin/qemu-ifup,downscript=/usr/sbin/qemu-ifdown -monitor unix:/var/run/kvm/fs-01/monitor,server,nowait -pidfile /var/run/kvm/fs-01/pid -k de -kernel /srv/kvm/kernel/linux-2.6.38-gentoo -append root=/dev/vda -vnc :0 -name fs-01,process=fs-01 -vga std + +Triaging old bug tickets... QEMU 0.13 and 0.14 are pretty outdated nowadays, can you still reproduce this behavior with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/760956 b/results/classifier/118/x86/760956 new file mode 100644 index 000000000..51a93bb90 --- /dev/null +++ b/results/classifier/118/x86/760956 @@ -0,0 +1,59 @@ +x86: 0.850 +graphic: 0.790 +mistranslation: 0.772 +semantic: 0.713 +architecture: 0.599 +user-level: 0.530 +boot: 0.500 +performance: 0.497 +device: 0.474 +virtual: 0.384 +socket: 0.378 +i386: 0.360 +network: 0.351 +hypervisor: 0.342 +permissions: 0.338 +peripherals: 0.297 +files: 0.285 +PID: 0.282 +debug: 0.275 +vnc: 0.265 +register: 0.229 +ppc: 0.224 +kernel: 0.184 +arm: 0.162 +risc-v: 0.152 +TCG: 0.130 +VMM: 0.099 +assembly: 0.091 +KVM: 0.075 + +Open Solaris 2009 Doesn't Boot + +The latest git version of qemu (commit 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the OpenSolaris image from http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso. + +qemu-img create opensolaris 3G +qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d -redir tcp:2232::22 -k en-us -m 192 + +gives: + +... +Trying cdrom:d +File not found +Trying cdrom... +Not a bootable ELF image +Not a bootable a.out image +No valid state has been set by load or init_program + +Host: Linux/x86_64 +gcc4.5 +./configure --enable-linux-aio --enable-io-thread --enable-kvm + +Are you sure that it boots on real hardware? From the information given in +http://dlc.sun.com.edgesuite.net/osol/opensolaris/2009/06/README.osol-repo +I'd expect that this image is not bootable from CD-ROM. + +A Debian CD-ROM boots without any problem. + +The URLs don't work any more, and according to Stefan's comment, this was likely not a bug, so I'm closing this ticket now (feel free to open it again if you don't agree). + diff --git a/results/classifier/118/x86/796480 b/results/classifier/118/x86/796480 new file mode 100644 index 000000000..ea8a51789 --- /dev/null +++ b/results/classifier/118/x86/796480 @@ -0,0 +1,80 @@ +x86: 0.835 +architecture: 0.777 +performance: 0.722 +graphic: 0.704 +kernel: 0.680 +device: 0.655 +user-level: 0.638 +assembly: 0.454 +permissions: 0.448 +ppc: 0.399 +mistranslation: 0.398 +semantic: 0.373 +PID: 0.346 +vnc: 0.337 +debug: 0.269 +arm: 0.263 +register: 0.223 +hypervisor: 0.214 +socket: 0.200 +VMM: 0.181 +files: 0.170 +virtual: 0.158 +risc-v: 0.147 +peripherals: 0.144 +TCG: 0.132 +boot: 0.116 +i386: 0.113 +network: 0.110 +KVM: 0.093 + +Addresses with 4GB differences are consider as one single address in QEMU + +THIS IS THE ISSUE OF USER MODE EMULATION +Information about guest and host +********************************** +guest: 64 bit x86 user mode binary +host: 32 bit Linux OS +uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP +architecture: intel64 +Bug Description +**************** +for memory reference instructions, suppose I have two addresses in guest address space(64 bit) +0x220000000 +0x320000000 +as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) +in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. +here is the program which i used to test: +#include <stdio.h> +#include <stdlib.h> +#include <limits.h> +#define SIZE 4294967298 /* 4Gib*/ + +int main() { + char *array; + unsigned int i; + + array = malloc(sizeof(char) * SIZE); + if(array == NULL) { + fprintf(stderr, "Could not allocate that much memory"); + return 1; } + array[0] = 'a'; + array[SIZE-2] = 'z'; + printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); + return 0; +} +I have 8 gib RAM +I compiled this program on 64 bit linux and run this on 32 bit linux with qemu +QEMU command line and output +********************************** +$x86_64-linux-user/qemu-x86_64 ~/ar_x86 +output: array[SIZE-1] = z,array[0] = z +Release information +******************** +x86_64 binary is tested with latest release : qemu-0.14.1 +and with current development tree as well( live code of QEMU using git) + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/x86/798 b/results/classifier/118/x86/798 new file mode 100644 index 000000000..65de410bd --- /dev/null +++ b/results/classifier/118/x86/798 @@ -0,0 +1,45 @@ +x86: 0.943 +graphic: 0.915 +device: 0.873 +permissions: 0.854 +files: 0.828 +network: 0.808 +kernel: 0.781 +architecture: 0.777 +hypervisor: 0.712 +PID: 0.708 +vnc: 0.695 +performance: 0.670 +socket: 0.637 +i386: 0.631 +boot: 0.628 +ppc: 0.614 +debug: 0.589 +TCG: 0.585 +VMM: 0.534 +register: 0.527 +peripherals: 0.502 +risc-v: 0.486 +semantic: 0.445 +KVM: 0.416 +arm: 0.336 +user-level: 0.252 +virtual: 0.239 +assembly: 0.189 +mistranslation: 0.136 + +The sandbox option elevelateprivileges=deny does not work with -daemonize +Description of problem: +qemu will not launch if `-sandbox on,elevateprivileges=deny` and `-daemonize` are set at the same time. +Steps to reproduce: +``` +qemu-system-x86_64 -sandbox on,elevateprivileges=deny -nodefaults -daemonize +``` +-> fails to launch + +``` +qemu-system-x86_64 -sandbox on -nodefaults -daemonize +``` +-> runs normally +Additional information: +[journal.txt](/uploads/c0e2a973e749011c3b1ac2158420a4e8/journal.txt) diff --git a/results/classifier/118/x86/824 b/results/classifier/118/x86/824 new file mode 100644 index 000000000..7a3ad4190 --- /dev/null +++ b/results/classifier/118/x86/824 @@ -0,0 +1,42 @@ +x86: 0.967 +graphic: 0.848 +device: 0.834 +architecture: 0.703 +kernel: 0.641 +mistranslation: 0.623 +debug: 0.586 +vnc: 0.563 +PID: 0.485 +semantic: 0.474 +socket: 0.455 +assembly: 0.442 +TCG: 0.386 +network: 0.345 +arm: 0.344 +ppc: 0.329 +performance: 0.322 +risc-v: 0.295 +boot: 0.225 +VMM: 0.208 +files: 0.152 +user-level: 0.111 +i386: 0.102 +permissions: 0.102 +register: 0.082 +virtual: 0.051 +peripherals: 0.040 +hypervisor: 0.034 +KVM: 0.024 + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/118/x86/825776 b/results/classifier/118/x86/825776 new file mode 100644 index 000000000..259b282ad --- /dev/null +++ b/results/classifier/118/x86/825776 @@ -0,0 +1,47 @@ +x86: 0.862 +architecture: 0.777 +device: 0.767 +ppc: 0.728 +graphic: 0.562 +socket: 0.469 +PID: 0.451 +semantic: 0.423 +performance: 0.423 +boot: 0.399 +mistranslation: 0.394 +peripherals: 0.346 +permissions: 0.327 +vnc: 0.273 +user-level: 0.259 +register: 0.255 +hypervisor: 0.245 +VMM: 0.228 +risc-v: 0.203 +files: 0.196 +TCG: 0.158 +debug: 0.134 +network: 0.101 +KVM: 0.078 +assembly: 0.078 +arm: 0.068 +virtual: 0.055 +kernel: 0.042 +i386: 0.034 + +-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??? + +All working now, I think some BIOS files were missing. Please close this bug report. + diff --git a/results/classifier/118/x86/889053 b/results/classifier/118/x86/889053 new file mode 100644 index 000000000..5375f25dc --- /dev/null +++ b/results/classifier/118/x86/889053 @@ -0,0 +1,80 @@ +x86: 0.855 +architecture: 0.770 +mistranslation: 0.767 +i386: 0.747 +device: 0.640 +kernel: 0.567 +user-level: 0.548 +graphic: 0.544 +hypervisor: 0.539 +socket: 0.539 +ppc: 0.535 +files: 0.525 +performance: 0.524 +peripherals: 0.507 +vnc: 0.495 +semantic: 0.495 +risc-v: 0.448 +PID: 0.429 +network: 0.411 +permissions: 0.383 +arm: 0.382 +VMM: 0.359 +TCG: 0.331 +boot: 0.317 +register: 0.316 +debug: 0.312 +virtual: 0.310 +KVM: 0.296 +assembly: 0.277 + +x86: FPU_MAX, FPU_MIN incorrect + +Dear All, + +Bug was found in qemu.git. +Now (0.15, 1.0) all fpu is softfpu. +See target-i386/ops_sse.h: +#define FPU_MIN(size, a, b) (a) < (b) ? (a) : (b) +#define FPU_MAX(size, a, b) (a) > (b) ? (a) : (b) +It is incorrect now, becouse float64 (or 32) is (typedef) uint64_t (or 32). +And if we have signed operands we get error... + +There is a test with this error (spec shinx3 test data, results diffs on machine and qemu (linux)) and fixed patch. See attach. + +Daniil. + + + + + +misprint: +spec sphinx3 test data + +482.sphinx3: http://www.spec.org/cpu2006/CFP2006/ + +The attached patch is incorrect (using the softfloat _min/_max functions will give wrong answers for some special cases). The correct macros are +#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, &env->sse_status) ? (a) : (b) +#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, &env->sse_status) ? (a) : (b) + +(see recent discussion on the qemu-devel list). + + +Hello! +Can I commit this patch (in development branch), and close this bug... +Or you must do it? + +Your patch is broken, as I said before. + + +Yes, but you patch is correct... + +May be commit you patch + +I say about +#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, &env->sse_status) ? (a) : (b) +#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, &env->sse_status) ? (b) : (a) + +The patch mentioned in comment #5 has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a4d1f142542935b90d2e + diff --git a/results/classifier/118/x86/891002 b/results/classifier/118/x86/891002 new file mode 100644 index 000000000..0999d7a15 --- /dev/null +++ b/results/classifier/118/x86/891002 @@ -0,0 +1,74 @@ +x86: 0.878 +TCG: 0.781 +architecture: 0.724 +peripherals: 0.692 +performance: 0.601 +debug: 0.590 +user-level: 0.587 +semantic: 0.523 +files: 0.497 +device: 0.455 +hypervisor: 0.397 +graphic: 0.374 +PID: 0.351 +permissions: 0.324 +boot: 0.318 +network: 0.316 +register: 0.314 +ppc: 0.261 +risc-v: 0.251 +kernel: 0.248 +vnc: 0.246 +VMM: 0.240 +socket: 0.239 +mistranslation: 0.234 +virtual: 0.210 +KVM: 0.202 +arm: 0.183 +assembly: 0.096 +i386: 0.092 + +windows mingw compiled qemu-system-x86_64 crash on startup + +qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +$3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} + +it's compiled on windows 2003 and using mingw gcc version 4.6.1 + + +On Wed, Nov 16, 2011 at 7:01 AM, humeafo <email address hidden> wrote: +> Public bug reported: +> +> qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +> $3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} + +Kevin: Is this similar to the issue you found with your mingw cross-compiler? + +Stefan + + +Am 16.11.2011 11:35, schrieb Stefan Hajnoczi: +> On Wed, Nov 16, 2011 at 7:01 AM, humeafo <email address hidden> wrote: +>> Public bug reported: +>> +>> qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +>> $3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} +> +> Kevin: Is this similar to the issue you found with your mingw cross-compiler? + +The symptoms were different. I didn't get a broken TCG state but some +internals of the Fiber used for coroutines must have been corrupted +(SwitchFiber() crashed when dereferencing a null pointer, but the +externally visible pointer that qemu passed to it was still ok). + +Maybe both could be symptoms of the same kind of memory corruption. + +Kevin + + +maybe it's caused by mingw/gcc? the same binary runs well on win7-x64, but not on win2003-32 bit I'll do more test, if I've time, i'd debug it and try to find the reason + +after some debugging I confirmed that this is caused by a mingw gcc 4.6.1-2 optiomization bug, gcc generated optimized code that used ebp to store some results , while later ebp is used in setjmp and longjmp, so a beiju occurred. mingw gcc 4.5.2works well. the bug should be closed. + +Closing according to comment #5. + diff --git a/results/classifier/118/x86/932 b/results/classifier/118/x86/932 new file mode 100644 index 000000000..2c598067c --- /dev/null +++ b/results/classifier/118/x86/932 @@ -0,0 +1,44 @@ +x86: 0.949 +device: 0.899 +vnc: 0.886 +ppc: 0.822 +risc-v: 0.785 +PID: 0.771 +kernel: 0.759 +performance: 0.758 +graphic: 0.746 +virtual: 0.720 +socket: 0.709 +architecture: 0.693 +i386: 0.682 +debug: 0.682 +hypervisor: 0.677 +VMM: 0.676 +mistranslation: 0.665 +semantic: 0.604 +permissions: 0.575 +register: 0.573 +TCG: 0.557 +KVM: 0.524 +boot: 0.506 +arm: 0.466 +network: 0.390 +files: 0.311 +peripherals: 0.265 +user-level: 0.205 +assembly: 0.200 + +Snapshot created with 6.2.0 cannot be loaded with 7.0.0-rc1 +Description of problem: +Loading the snapshot will fail with: + +```` +qemu-system-x86_64: Missing section footer for 0000:00:01.3/piix4_pm +qemu-system-x86_64: Error -22 while loading VM state +```` +Steps to reproduce: +1. Start VM with `6.2.0`. +2. Create a snapshot `takenwith620` with `snapshot-save` QMP command. +3. Stop VM and try to load snapshot with `v7.0.0-rc1`. +Additional information: +Bisecting led to `5ead62185d ("memory: Make memory_region_is_mapped() succeed when mapped via an alias")`, but reverting that alone wasn't enough, so I continued and got to `7c0fa8dff8 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)")`. Only reverting both seems to fix the issue. diff --git a/results/classifier/118/x86/996 b/results/classifier/118/x86/996 new file mode 100644 index 000000000..11118fc73 --- /dev/null +++ b/results/classifier/118/x86/996 @@ -0,0 +1,56 @@ +x86: 0.947 +device: 0.797 +graphic: 0.696 +architecture: 0.622 +performance: 0.621 +i386: 0.511 +ppc: 0.486 +semantic: 0.473 +PID: 0.469 +network: 0.354 +mistranslation: 0.304 +socket: 0.266 +register: 0.260 +kernel: 0.254 +permissions: 0.252 +vnc: 0.245 +hypervisor: 0.237 +user-level: 0.231 +arm: 0.230 +TCG: 0.227 +boot: 0.216 +risc-v: 0.212 +peripherals: 0.170 +debug: 0.162 +VMM: 0.149 +virtual: 0.143 +KVM: 0.100 +files: 0.098 +assembly: 0.074 + +Alt-TAB minimizes a full screen key-grabbed SDL window +Description of problem: +I was made aware of a case where a qemu seems to respond to a keyboard event `Alt+Tab` that isn't meant for it. + +When running in "SDL + full-screen + keys being grabbed by the guest" (see steps to reproduce below) one would expect `Alt+Tab` to do nothing on the host. But it does minimize the qemu window. + +This does not happen if: +- using GTK instead of SDL +- not being in full-screen mode + +No error message or warning appears while this happens. +Steps to reproduce: +You do not need and workload to run inside qemu for this + +1. `qemu-system-x86_64 -display sdl` +2. Get your key grabbed: `click inside the window` +3. Go full screen: `Alt+Ctrl+F` +4. Press `Alt+Tab` +5. Expected: nothing, Experienced: window minimizes + +Note: it even is reproducible if running the qemu binary from another system through SSH with X11 forwarding. + +P.S. +I haven't had a chance yet to try qemu 7.0 from git, but will in a bit. +It is easy enough to reproduce that I considered it worth filing without. +For the start it would be great to hear if others see that as well or not. In case of the latter we'd have to compare library versions (currently I use sdl 2.0.20+dfsg-2build1). |