diff options
Diffstat (limited to 'results/classifier/118/i386')
44 files changed, 2401 insertions, 0 deletions
diff --git a/results/classifier/118/i386/1159 b/results/classifier/118/i386/1159 new file mode 100644 index 000000000..70500cd6d --- /dev/null +++ b/results/classifier/118/i386/1159 @@ -0,0 +1,62 @@ +i386: 0.928 +graphic: 0.826 +device: 0.655 +boot: 0.611 +x86: 0.606 +PID: 0.506 +vnc: 0.502 +socket: 0.497 +kernel: 0.482 +files: 0.465 +debug: 0.464 +network: 0.456 +register: 0.428 +ppc: 0.390 +permissions: 0.343 +risc-v: 0.319 +performance: 0.284 +architecture: 0.283 +semantic: 0.281 +VMM: 0.274 +arm: 0.269 +assembly: 0.268 +hypervisor: 0.267 +TCG: 0.242 +user-level: 0.206 +KVM: 0.206 +peripherals: 0.181 +mistranslation: 0.127 +virtual: 0.127 + +Strange invalid access errors for very basic OS +Description of problem: +Currently I'm studying OS development. I found numerous guides on that topic, however [this one](https://github.com/cfenollosa/os-tutorial/tree/master/01-bootsector-barebones) is most close to what I have been doing. +When `.bin` file is launched with `-d guest_errors` flag, before any OS output exactly 512 error messages appear in logs, that look like that: +``` +Invalid access at addr 0xFEBB0000, size 1, region '(null)', reason: rejected +Invalid access at addr 0x0, size 1, region '(null)', reason: rejected +Invalid access at addr 0xFEBB0001, size 1, region '(null)', reason: rejected +Invalid access at addr 0x1, size 1, region '(null)', reason: rejected +Invalid access at addr 0xFEBB0002, size 1, region '(null)', reason: rejected +... +and it goes up to +... +Invalid access at addr 0xFEBB00FE, size 1, region '(null)', reason: rejected +Invalid access at addr 0xFE, size 1, region '(null)', reason: rejected +Invalid access at addr 0xFEBB00FF, size 1, region '(null)', reason: rejected +Invalid access at addr 0xFF, size 1, region '(null)', reason: rejected +``` +Apparently, the OS boots normally after that. Should I be concerned about these messages or Should I just ignore them? +That looks strange and confusing, not a piece of my code calls these addresses. Maybe I'm doing something wrong? +Steps to reproduce: +1. Install `nasm` compiler (nasm package for apt) +2. Create a file named `os.asm` with exactly four lines: +```asm +loop: + jmp loop +times 510-($-$$) db 0 +dw 0xaa55 +``` +3. Build it with `nasm -f bin os.asm -o os.bin` +4. Run it with `qemu-system-i386 -d guest_errors -drive format=raw,file=./os.bin` +5. ...enjoy error messages. diff --git a/results/classifier/118/i386/1165383 b/results/classifier/118/i386/1165383 new file mode 100644 index 000000000..07ac6188c --- /dev/null +++ b/results/classifier/118/i386/1165383 @@ -0,0 +1,46 @@ +i386: 0.978 +device: 0.767 +user-level: 0.747 +network: 0.620 +mistranslation: 0.582 +x86: 0.556 +graphic: 0.550 +register: 0.530 +semantic: 0.516 +debug: 0.444 +PID: 0.440 +socket: 0.425 +boot: 0.393 +architecture: 0.370 +ppc: 0.364 +virtual: 0.345 +vnc: 0.313 +KVM: 0.295 +permissions: 0.291 +files: 0.269 +arm: 0.257 +kernel: 0.229 +risc-v: 0.220 +hypervisor: 0.183 +VMM: 0.180 +TCG: 0.175 +peripherals: 0.142 +performance: 0.123 +assembly: 0.044 + +executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault + +executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault + +Can you please provide some more information here. + +e.g. + + - qemu command-line used + - how did you trigger it - libvirt/or direct qemu-kvm binary + - segentation fault/tracedetails + + +I'm going to close this bug, since there was no response to the 2013 request for more detail. If you're still having problems with QEMU, please open a fresh bug report. + + diff --git a/results/classifier/118/i386/1175 b/results/classifier/118/i386/1175 new file mode 100644 index 000000000..70ebfb44f --- /dev/null +++ b/results/classifier/118/i386/1175 @@ -0,0 +1,38 @@ +i386: 0.978 +graphic: 0.809 +architecture: 0.726 +x86: 0.678 +device: 0.666 +ppc: 0.441 +arm: 0.435 +risc-v: 0.358 +files: 0.330 +network: 0.215 +vnc: 0.186 +semantic: 0.159 +boot: 0.141 +socket: 0.132 +performance: 0.130 +debug: 0.102 +PID: 0.099 +TCG: 0.074 +mistranslation: 0.073 +user-level: 0.069 +virtual: 0.066 +permissions: 0.066 +register: 0.063 +kernel: 0.046 +VMM: 0.041 +peripherals: 0.034 +hypervisor: 0.015 +assembly: 0.008 +KVM: 0.002 + +Crash / Assert in VVFAT.c while installaling WinXP from QEMU 7.0 running in Raspberry OS +Description of problem: +- Windows XP installation crashes QEMU with : +qemu-system-i386: ../block/vvfat.c:103: array_get: Assertion `index < array->next' failed. +Steps to reproduce: +Use command line above and run WindowsXP installation +Additional information: +Execution also leads to many "Invalid file name" being reported by QEMU diff --git a/results/classifier/118/i386/1207228 b/results/classifier/118/i386/1207228 new file mode 100644 index 000000000..a1eed0d10 --- /dev/null +++ b/results/classifier/118/i386/1207228 @@ -0,0 +1,48 @@ +i386: 0.973 +device: 0.733 +performance: 0.714 +x86: 0.680 +graphic: 0.672 +architecture: 0.616 +network: 0.614 +ppc: 0.611 +socket: 0.604 +PID: 0.563 +permissions: 0.545 +register: 0.533 +semantic: 0.533 +mistranslation: 0.429 +peripherals: 0.415 +TCG: 0.387 +vnc: 0.378 +files: 0.365 +boot: 0.361 +debug: 0.352 +kernel: 0.274 +hypervisor: 0.253 +arm: 0.253 +risc-v: 0.226 +virtual: 0.201 +VMM: 0.189 +user-level: 0.174 +assembly: 0.133 +KVM: 0.077 + +Qemu (trunk code) crashes when using --soundhw all option in ioport.c + +After not building qemu (git version) for about 3 weeks, I've done it again this morning. + +With up-to-date trunk code, I got this error on start, when using --soundhw all option + +$ qemu-system-i386 -soundhw all +qemu-system-i386: /home/fred/Téléchargements/logs/qemu-git/src/qemu/ioport.c:240: portio_list_add: Assertion `pio->offset >= off_last' failed. +Abandon (core dumped) + +And if I use only soundhw with one or more options, it doesn't crash. + +Tell me what you'll need to fix this bug. + +Please always specify the exact version (git commit ID) that you are using... can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/i386/1223477 b/results/classifier/118/i386/1223477 new file mode 100644 index 000000000..3c9134832 --- /dev/null +++ b/results/classifier/118/i386/1223477 @@ -0,0 +1,65 @@ +i386: 0.871 +semantic: 0.769 +files: 0.734 +x86: 0.719 +architecture: 0.712 +peripherals: 0.705 +device: 0.692 +graphic: 0.607 +socket: 0.605 +performance: 0.567 +assembly: 0.553 +ppc: 0.494 +PID: 0.467 +user-level: 0.446 +mistranslation: 0.431 +kernel: 0.430 +debug: 0.420 +permissions: 0.418 +register: 0.410 +vnc: 0.379 +boot: 0.374 +network: 0.372 +hypervisor: 0.344 +VMM: 0.303 +arm: 0.299 +risc-v: 0.259 +KVM: 0.252 +TCG: 0.224 +virtual: 0.218 + +Unable to read USB filesystems with EFI Bios + +Preamble and version: +With respect to my fix for using USB devices as -hda mentioned in bug 1223467 +Using Qemu 1.6.0 with OVMF r11337-alpha (Qemu is built from Source, OVMF is pre built) + +Command: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 + +Fault: +The EFI Shell is able to detect the hda block device, report its capacity and usage; +but it sees no files or directories on the device. + +Similar commands: +I have also seen the same with +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 +and +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-x64 + +Investigations: +I tried very small (500MB) and very large (32 GB) USB devices with no difference. +I re-built several versions of Qemu in an identical build environment, and found that: +Qemu 1.2.2 and before, all the above commands work and the EFI boot loader is called. +Qemu 1.3.0-rc0 and after do not work and the USB device appears blank. +I'm reporting the bug here and not with OVMF because older versions of Qemu with the same OVMF bios work perfectly. + +In all cases using '-L pc-bios' works perfectly. +In all cases using an image of the USB device works. + +Thanks + +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/i386/1258626 b/results/classifier/118/i386/1258626 new file mode 100644 index 000000000..df932d52f --- /dev/null +++ b/results/classifier/118/i386/1258626 @@ -0,0 +1,56 @@ +i386: 0.934 +graphic: 0.759 +device: 0.726 +x86: 0.688 +semantic: 0.624 +mistranslation: 0.522 +performance: 0.506 +user-level: 0.479 +architecture: 0.435 +debug: 0.413 +peripherals: 0.404 +permissions: 0.389 +ppc: 0.374 +files: 0.342 +socket: 0.338 +network: 0.335 +virtual: 0.324 +vnc: 0.314 +register: 0.297 +kernel: 0.285 +risc-v: 0.281 +arm: 0.269 +PID: 0.260 +boot: 0.221 +hypervisor: 0.219 +TCG: 0.152 +VMM: 0.114 +assembly: 0.104 +KVM: 0.051 + +Curses Keyboard Broken On OS X + +Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k en-gb'') on OS X 10.9, the keyboard does not work properly. For example, when attempting to switch to the QEMU console with Alt+2, I get: + +``Warning: no scancode found for keysym 226 +Warning: no scancode found for keysym 130 +Warning: no scancode found for keysym 172'' + +I have checked and these scancodes are not mentioned in ``share/qemu/keymaps/''. + +EDIT: I should have mentioned that this is using QEMU 1.6.1, but the problem also occurs with 1.3.1. Also, in case it makes a difference, I installed QEMU using Homebrew. + +Does the problem still occur with the latest version of QEMU (currently v2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + +Yes, I can still reproduce this with 2.8.0, and it gives exactly the same output. + + +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/98 + + diff --git a/results/classifier/118/i386/1269 b/results/classifier/118/i386/1269 new file mode 100644 index 000000000..a458cf162 --- /dev/null +++ b/results/classifier/118/i386/1269 @@ -0,0 +1,56 @@ +i386: 0.976 +PID: 0.883 +kernel: 0.879 +device: 0.808 +network: 0.786 +boot: 0.785 +graphic: 0.770 +vnc: 0.666 +performance: 0.611 +TCG: 0.572 +permissions: 0.568 +socket: 0.529 +x86: 0.528 +semantic: 0.525 +files: 0.506 +register: 0.483 +ppc: 0.467 +architecture: 0.434 +mistranslation: 0.411 +debug: 0.367 +risc-v: 0.350 +arm: 0.305 +VMM: 0.286 +user-level: 0.205 +virtual: 0.173 +peripherals: 0.164 +hypervisor: 0.097 +KVM: 0.070 +assembly: 0.065 + +qemu-system-i386 no longer boots NetBSD +Description of problem: +Since qemu commit e3a79e0e87831602e41819591a8e6dcc70a2a231, NetBSD +no longer boots under qemu-system-i386. +Steps to reproduce: +1. `wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/i386/installation/cdrom/boot-com.iso` +2. `qemu-system-i386 -nographic -cdrom boot-com.iso` + +Expected behavior: the system boots and prompts you for a terminal type with + + Terminal type (just hit ENTER for 'vt220'): + +Observed incorrect behavior: the guest kernel either hangs during boot at + + Loading /stand/i386/9.2/modules/cd9660/cd9660.kmod + WARNING: 1 module failed to load + +or panics during boot with + + kernel: supervisor trap page fault, code=0 + Stopped in pid 0.1 (system) at netbsd:idt_vec_reserve+0xa: cmpb $0,netbs + d:idt_allocmap(%ebx) + db{0}> +Additional information: +This regression is a critical issue to the NetBSD project as its automated +testing infrastructure is heavily dependent on qemu-system-i386. diff --git a/results/classifier/118/i386/1326986 b/results/classifier/118/i386/1326986 new file mode 100644 index 000000000..1e10cd505 --- /dev/null +++ b/results/classifier/118/i386/1326986 @@ -0,0 +1,49 @@ +i386: 0.963 +x86: 0.948 +device: 0.891 +debug: 0.820 +peripherals: 0.791 +network: 0.743 +ppc: 0.633 +socket: 0.588 +PID: 0.583 +virtual: 0.569 +performance: 0.557 +boot: 0.554 +architecture: 0.553 +vnc: 0.525 +hypervisor: 0.482 +semantic: 0.468 +permissions: 0.448 +graphic: 0.437 +register: 0.428 +files: 0.412 +user-level: 0.352 +mistranslation: 0.314 +VMM: 0.264 +assembly: 0.236 +kernel: 0.225 +risc-v: 0.205 +TCG: 0.163 +arm: 0.159 +KVM: 0.020 + +e1000 - no link detected by VXWorks based guest + +I'm trying to get a VXWorks image running inside a qemu guest. I have the machine running, however, the vxworks image only has support for the 82544EI device so I had to change the device ID in e1000.c to get the device even recognized so I'm not sure if this is a bug or an issue for the development list. + + +After changing e1000.c, the device is now seen by the guest OS, however, it never gets a link. I've attached the e1000 debug logs in the hopes that someone can help me understand where to start looking into why this guest won't get a link. + +I tested the updated e1000 driver with a debian live CD and the card works under it, so it doesn't appear that the issue is with the driver string change but rather something in the e1000 driver itself. + +Here is the command I'm using to start QEMU: + +/opt/qemu/bin/qemu-system-i386 -cpu coreduo -hda /root/vxworks_test -m 2048 -netdev tap,ifname=tap0,id=net0 -netdev tap,ifname=tap1,id=net1 -device e1000,netdev=net0,mac=00:00:e8:01:02:03 -device e1000,netdev=net1,mac=00:00:e8:01:02:04 -boot c -curses -no-kvm -D /tmp/qemu.log 2>/tmp/e1000.log + + + +Triaging old bug tickets... Which version of QEMU have you been using here? 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/i386/1338591 b/results/classifier/118/i386/1338591 new file mode 100644 index 000000000..67af45397 --- /dev/null +++ b/results/classifier/118/i386/1338591 @@ -0,0 +1,74 @@ +i386: 0.925 +graphic: 0.875 +peripherals: 0.795 +hypervisor: 0.794 +virtual: 0.790 +performance: 0.770 +device: 0.743 +user-level: 0.738 +ppc: 0.734 +kernel: 0.700 +files: 0.676 +architecture: 0.672 +debug: 0.660 +semantic: 0.603 +PID: 0.596 +x86: 0.532 +permissions: 0.528 +socket: 0.502 +risc-v: 0.495 +register: 0.472 +KVM: 0.428 +VMM: 0.424 +network: 0.420 +mistranslation: 0.408 +assembly: 0.392 +vnc: 0.369 +TCG: 0.368 +boot: 0.360 +arm: 0.326 + +Cursor jumps on shape change with vmware vga + +I launch QEMU with the following command line: + +qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm + +The guest OS is Windows XP. To reproduce the problem, do this: + +0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA +1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. +2. Open a text editor, e.g. built-in notepad +3. Move the cursor inside text entry widget +4. See the cursor jumping away. You basically can't enter the cursor there. + +This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. + +This doesn't happen with other VGAs, i.e. cirrus and std. + +I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. + +I've checked with Kubuntu 14.04 LiveCD as guest, and there's no such problem. +What seems relevant is that in Kubuntu mouse cursor seamlessly enters and exits the window, i.e. mouse is automatically grabbed and ungrabbed, while on WinXP guest it's not supported (I think I just didn't install such a driver). Maybe it's this mode which makes behavior different. + +After some experimenting it starts to seem that this is a special case of a more general problem with HW accelerated cursor. This particular bug can be reproduced without any edit field — it's enough to try moving the classical cursor (i.e. HW accelerated as set in 1. in bug description) over some window edges so that it changes its shape to resize arrows and back to usual pointer. + +Now, it appears that if I set mouse cursor speed to smallest possible, then the cursor moves _very_ jittery. It is close to unusable. + +This may indicate some principal problem with such implementation of HW accelerated cursor. What if instead of using the real system cursor QEMU would create a (undecorated) window which would be the guest cursor, still rendered with some HW acceleration? In this case it'd be not necessary to always have the real cursor near the guest cursor, in fact the video driver won't even touch the real cursor at all. + +Setting SDL_VIDEO_X11_DGAMOUSE=0 environment variable works around this problem. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +I still reproduce this with QEMU v2.10.0-1649-ga93ece4. + + +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/104 + + diff --git a/results/classifier/118/i386/1366363 b/results/classifier/118/i386/1366363 new file mode 100644 index 000000000..520597f2a --- /dev/null +++ b/results/classifier/118/i386/1366363 @@ -0,0 +1,64 @@ +i386: 0.858 +graphic: 0.853 +device: 0.613 +architecture: 0.563 +peripherals: 0.472 +socket: 0.464 +semantic: 0.436 +performance: 0.411 +network: 0.404 +vnc: 0.385 +x86: 0.357 +ppc: 0.354 +files: 0.322 +PID: 0.308 +hypervisor: 0.299 +risc-v: 0.282 +user-level: 0.274 +virtual: 0.269 +register: 0.262 +kernel: 0.260 +arm: 0.255 +permissions: 0.224 +mistranslation: 0.207 +boot: 0.193 +TCG: 0.164 +VMM: 0.145 +assembly: 0.123 +debug: 0.122 +KVM: 0.094 + +qemu-git gravis ultrasound not working + +Qemu git 2.1.50 with dos622 and windows 3.11. + +Parameter: + +For build: default-configs/sound.mak CONFIG_GUS=y + +Starting parameter: qemu-system-i386 -cpu 486 -m 32M -vga cirrus -hda disk1.img -soundhw gus,pcspk -parallel none -net nic,model=ne2k_isa -net user + +The installer of GUS driver 4.11 does not recognize the card. And conscan tells me that ioport 220-240 and not safe for synth base. It seems that there is a port conflict. + + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +The problem seems to exist for a long time. I have tried it today with both: +qemu-system-i386 ./msdos.disk -device gus,irq=5 -parallel none +and +qemu-system-x86_64 ./msdos.disk -device gus,irq=5 -parallel none + +with and without providing the irq parameter and gus does not install with conscan showing: +file:///tmp/gnome-shell-screenshot-5N7FP0.png + +The conscan screenshot for my previous post ... + + +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/106 + + diff --git a/results/classifier/118/i386/1429313 b/results/classifier/118/i386/1429313 new file mode 100644 index 000000000..e7353e9b6 --- /dev/null +++ b/results/classifier/118/i386/1429313 @@ -0,0 +1,45 @@ +i386: 0.974 +mistranslation: 0.413 +device: 0.389 +graphic: 0.286 +network: 0.262 +performance: 0.242 +socket: 0.231 +semantic: 0.163 +kernel: 0.148 +architecture: 0.145 +register: 0.119 +PID: 0.109 +permissions: 0.096 +vnc: 0.096 +boot: 0.087 +debug: 0.087 +arm: 0.058 +files: 0.053 +ppc: 0.052 +virtual: 0.049 +user-level: 0.047 +hypervisor: 0.043 +x86: 0.039 +risc-v: 0.037 +KVM: 0.034 +assembly: 0.029 +VMM: 0.027 +peripherals: 0.019 +TCG: 0.017 + +qemu-user doesn't block target signals on entry to signal hanlder. + +Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler. + +The attached test case my be run as: + +$ (sleep 2 ; echo) | qemu-i386 ./a.out +.................. Recursion in signal handler! +qemu: uncaught target signal 6 (Aborted) - core dumped + + + +The patches to block signals on entry to the signal handler have now been applied to master. + + diff --git a/results/classifier/118/i386/1437367 b/results/classifier/118/i386/1437367 new file mode 100644 index 000000000..13c5a9f5b --- /dev/null +++ b/results/classifier/118/i386/1437367 @@ -0,0 +1,67 @@ +i386: 0.857 +x86: 0.816 +files: 0.775 +device: 0.703 +semantic: 0.676 +graphic: 0.656 +performance: 0.645 +architecture: 0.622 +hypervisor: 0.621 +kernel: 0.594 +ppc: 0.548 +mistranslation: 0.520 +vnc: 0.508 +permissions: 0.508 +user-level: 0.506 +debug: 0.488 +peripherals: 0.473 +risc-v: 0.466 +PID: 0.466 +assembly: 0.446 +socket: 0.405 +register: 0.400 +network: 0.399 +boot: 0.378 +virtual: 0.345 +VMM: 0.326 +arm: 0.295 +KVM: 0.273 +TCG: 0.270 + +Qemu guest fails to write files with raw disk (like \\.\PhysicalDrive1) on Windows host. + +Qemu guest fails to write files with specifing raw disk like \\.\PhysicalDrive1 +full command line is below. +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi + +I found the reason is below aio_worker returns -EIO when flush operation. + +https://github.com/qemu/qemu/blob/master/block/raw-win32.c#L95 + +static int aio_worker(void *arg) +... + case QEMU_AIO_FLUSH: + if (!FlushFileBuffers(aiocb->hfile)) { + return -EIO; + } + +FlushFileBuffers always fails with GetLastError() == ERROR_INVALID_FUNCTION +I think this function doesn't support raw device. +For flushing, you might have to issue scsi/ata command or use another way. +Trying to just ignoring this error, writing function seems to be fine for me. + +Thanks +hiroaki + +The documentation of FlushFileBuffers() only mentions that consoles cannot be flushed. It doesn't specifically mention physical drives, but it does explicitly mention that whole volumes can be flushed this way: + +https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439%28v=vs.85%29.aspx + +Of course, I'm not really a Windows expert, so my reading of this may be wrong. If anyone knows how physical drives are supposed to be flushed other than with FlushFileBuffers(), we can certainly implement that in qemu. + +In any case, just disabling the flush is not advisable as it may harm data integrity in case of crashes/power failure. If you really want to disable it, the cache=unsafe option should avoid the calls. + +Is there still anything left to do here, 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/i386/1519037 b/results/classifier/118/i386/1519037 new file mode 100644 index 000000000..2abdc838a --- /dev/null +++ b/results/classifier/118/i386/1519037 @@ -0,0 +1,52 @@ +i386: 0.957 +graphic: 0.748 +architecture: 0.740 +semantic: 0.653 +device: 0.509 +x86: 0.344 +performance: 0.335 +socket: 0.306 +debug: 0.297 +network: 0.273 +mistranslation: 0.267 +register: 0.242 +user-level: 0.228 +kernel: 0.210 +risc-v: 0.208 +ppc: 0.205 +boot: 0.203 +vnc: 0.186 +arm: 0.176 +hypervisor: 0.175 +virtual: 0.159 +PID: 0.157 +VMM: 0.146 +permissions: 0.144 +files: 0.130 +TCG: 0.127 +peripherals: 0.093 +KVM: 0.059 +assembly: 0.047 + +qemu-i386 32-bit segfault + +I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? + +In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? + +Thanks! + +It seems this crash only happens in xterm (and not normal console). + +Having compared the respective environment vars the culprit turned out to be: + +TERM=xterm-color + +You're welcome. + + +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/i386/1529226 b/results/classifier/118/i386/1529226 new file mode 100644 index 000000000..fc85d22d5 --- /dev/null +++ b/results/classifier/118/i386/1529226 @@ -0,0 +1,68 @@ +i386: 0.866 +graphic: 0.733 +user-level: 0.716 +architecture: 0.645 +performance: 0.555 +semantic: 0.540 +device: 0.503 +permissions: 0.417 +ppc: 0.390 +x86: 0.364 +files: 0.351 +mistranslation: 0.307 +boot: 0.306 +PID: 0.289 +register: 0.288 +arm: 0.271 +peripherals: 0.248 +network: 0.247 +virtual: 0.209 +debug: 0.194 +socket: 0.193 +vnc: 0.176 +risc-v: 0.174 +TCG: 0.167 +hypervisor: 0.141 +kernel: 0.110 +assembly: 0.092 +VMM: 0.075 +KVM: 0.036 + +qemu-i386-user on 32-bit Linux: uncaught target signal 11 + +Even though the command I'm trying to run (a wrapper script for qemu-i386-user running rustc, the rust compiler) produces the expected compiled output, the build process is interrupted: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +i686-unknown-linux-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" +make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.rustc_back] Error 139 + +The stamp file is not being created so this could be about forking bash after finishing the wrapper script. + +Qemu was compiled from the latest git source. + +Hi; thanks for this bug report. Could you provide instructions for how to reproduce this bug, please? + + +My recollection is fuzzy but it would probably amount to something like this on any platform currently: + +- download rust-1.10 beta source https://static.rust-lang.org/dist/rustc-beta-src.tar.gz + +- download this stage0 snapshot https://www.dropbox.com/s/01ywl9mwwo6xojw/rust-stage0-2016-04-18-b324fa7-linux-armv7.tar.xz?dl=0 + +- unpack the stage0 rustc binary to ~/somewhere/bin, renaming it to rustc.bin, and create a wrapper script named rustc in that directory containing: + +`/usr/bin/qemu-arm ~/somewhere/rustc.bin "$@"` + +In the rustc source directory, start the rust bootstrap process (with LLVM 3.7 or higher installed) issuing the following command: +`./configure --enable-optimize --enable-local-rust --local-rust-root=~/somewhere --llvm-root=/usr` + +Followed by `make`. + +At the time of the original report, QEMU wasn't able to complete all crates' build commands naturally. (the stamp file had to be created manually to continue) + +A simpler way to reproduce would probably be to wrap the regular, installed rustc that way and try running some compilations using cargo. That should be enough to elicit the same problem. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/i386/1565395 b/results/classifier/118/i386/1565395 new file mode 100644 index 000000000..b2a14876f --- /dev/null +++ b/results/classifier/118/i386/1565395 @@ -0,0 +1,59 @@ +i386: 0.865 +x86: 0.846 +files: 0.820 +graphic: 0.769 +ppc: 0.724 +peripherals: 0.721 +permissions: 0.712 +user-level: 0.709 +device: 0.705 +architecture: 0.693 +register: 0.675 +debug: 0.653 +semantic: 0.651 +performance: 0.646 +PID: 0.619 +vnc: 0.595 +hypervisor: 0.569 +mistranslation: 0.554 +assembly: 0.551 +socket: 0.546 +network: 0.508 +kernel: 0.500 +arm: 0.474 +boot: 0.469 +risc-v: 0.462 +VMM: 0.446 +virtual: 0.362 +TCG: 0.291 +KVM: 0.218 + +qemu-2.4.1 fails when compiled against pulseaudio + +If I compile qemu-2.4.1 like this: + +CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe +-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local +--localstatedir=/var --libexecdir=/usr/local/lib/qemu +--interp-prefix=/usr/local/share/qemu --disable-smartcard-nss +--disable-curses --disable-brlapi --audio-drv-list="oss alsa sdl" +--target-list="i386-softmmu i386-linux-user x86_64-softmmu +x86_64-linux-user" --smbd=/usr/local/sbin/smbd + +find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \; + +make + +..it works fine. + +If I add pulseaudio dev files and use --audio-drv-list="oss alsa sdl pa", +then "qemu-system-x86_64 -blah-blah" opens a window, displays the bios +message and stops. Strace shows qemu is not hung, but loops continually. + +The same happens with qemu-2.2.1 and qemu-2.5.0. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or 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/i386/1580586 b/results/classifier/118/i386/1580586 new file mode 100644 index 000000000..bae4119f4 --- /dev/null +++ b/results/classifier/118/i386/1580586 @@ -0,0 +1,54 @@ +i386: 0.944 +mistranslation: 0.794 +graphic: 0.785 +x86: 0.773 +performance: 0.696 +device: 0.669 +user-level: 0.652 +semantic: 0.631 +ppc: 0.601 +network: 0.595 +hypervisor: 0.593 +architecture: 0.549 +PID: 0.533 +virtual: 0.512 +socket: 0.504 +register: 0.504 +kernel: 0.487 +vnc: 0.477 +permissions: 0.460 +VMM: 0.412 +boot: 0.412 +files: 0.411 +arm: 0.404 +risc-v: 0.373 +debug: 0.369 +peripherals: 0.339 +TCG: 0.327 +assembly: 0.326 +KVM: 0.161 + +Qemu WinXP SP3 second loadvm freezes Guest OS + +Using Qemu-system-i386 to run WinXP SP3 with the following command line: + +qemu-system-i386 -hda qcow2/windowsxp_32bits_dd.qcow2 -m 1024 -net user,smb=/shared -vga std -net nic,model=rtl8139 -rtc base=localtime,clock=vm -s -snapshot + +savevm works fine, and the first loadvm to the snapshot works properly, but the next ones will all freeze the guest OS. + +First I thought it was due to the clock but adding the rtc options did not fix it. + +Actually the following commands also produce the freeze : +savevm 1 +loadvm 1 +savevm 2 +loadvm 2 +Guest OS freezes. + + + +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 be + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/i386/1588473 b/results/classifier/118/i386/1588473 new file mode 100644 index 000000000..6c9174fdb --- /dev/null +++ b/results/classifier/118/i386/1588473 @@ -0,0 +1,57 @@ +i386: 0.934 +x86: 0.907 +PID: 0.896 +device: 0.843 +graphic: 0.814 +performance: 0.790 +user-level: 0.787 +mistranslation: 0.785 +semantic: 0.765 +hypervisor: 0.740 +files: 0.732 +network: 0.714 +peripherals: 0.700 +register: 0.694 +ppc: 0.686 +architecture: 0.662 +socket: 0.646 +debug: 0.629 +permissions: 0.619 +risc-v: 0.618 +vnc: 0.606 +virtual: 0.537 +arm: 0.535 +boot: 0.523 +VMM: 0.493 +kernel: 0.464 +assembly: 0.443 +TCG: 0.436 +KVM: 0.433 + +Qemu Mate 16.10 and Gtk dont build + +when i try to build last qemu 2.6 on 16.10 of ubuntu mate i have this. +note on 16.04 was building without problem + +LINK i386-softmmu/qemu-system-i386 +../ui/gtk.o: In function `gd_get_pointer': +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_seat_get_pointer' +../ui/gtk.o: In function `gd_grab_update': +/home/amigaone/src/qemu/ui/gtk.c:1339: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:1353: undefined reference to `gdk_seat_grab' +/home/amigaone/src/qemu/ui/gtk.c:1356: undefined reference to `gdk_seat_ungrab' +../ui/gtk.o: In function `gd_get_pointer': +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_seat_get_pointer' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_seat_get_pointer' +collect2: error: ld returned 1 exit status + +I think this should be fixed with this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=bb732ee78cee8688e74b0f67ff8 +If possible, please give it a try! + +Hi T, +tested but dont build with the patch too... gtk abi 3.0 are away for now + diff --git a/results/classifier/118/i386/1605443 b/results/classifier/118/i386/1605443 new file mode 100644 index 000000000..b2b695fe1 --- /dev/null +++ b/results/classifier/118/i386/1605443 @@ -0,0 +1,49 @@ +i386: 0.943 +arm: 0.862 +graphic: 0.828 +user-level: 0.768 +semantic: 0.715 +device: 0.704 +architecture: 0.688 +mistranslation: 0.607 +performance: 0.573 +debug: 0.568 +boot: 0.549 +register: 0.529 +PID: 0.520 +network: 0.513 +ppc: 0.500 +vnc: 0.471 +risc-v: 0.457 +permissions: 0.454 +socket: 0.445 +files: 0.438 +kernel: 0.417 +VMM: 0.341 +virtual: 0.313 +hypervisor: 0.283 +peripherals: 0.270 +TCG: 0.254 +x86: 0.251 +assembly: 0.219 +KVM: 0.130 + +QEMU epoll for i386-linux-user on arm host is broken in 2.6 + +I'm trying to get wine running on qemu-i386 on arm. + +I found that 2.5.1 is OK, but 2.6 is not. + +By bisecting, I found commit 928bed6a057cedd6110e634865e021a24029785a is the problem. + +I reverted this commit, and then epoll is OK now. + +It seems that the commit broke epoll of qemu-i386 on arm. + +Oh I have sent a patch to qemu-devel mailing list... + +(maybe the mail is rejected, as I'm using Yandex mail service...) + +This was fixed by commit d9fe91d8689b078ac, which went into the 2.7 release. + + diff --git a/results/classifier/118/i386/1657841 b/results/classifier/118/i386/1657841 new file mode 100644 index 000000000..3449734b1 --- /dev/null +++ b/results/classifier/118/i386/1657841 @@ -0,0 +1,46 @@ +i386: 0.917 +mistranslation: 0.717 +architecture: 0.714 +device: 0.699 +graphic: 0.685 +performance: 0.645 +boot: 0.605 +hypervisor: 0.537 +semantic: 0.508 +virtual: 0.388 +user-level: 0.370 +PID: 0.292 +ppc: 0.268 +vnc: 0.260 +register: 0.218 +socket: 0.202 +x86: 0.199 +debug: 0.174 +files: 0.171 +network: 0.159 +permissions: 0.155 +assembly: 0.114 +arm: 0.109 +peripherals: 0.102 +kernel: 0.082 +risc-v: 0.071 +VMM: 0.039 +TCG: 0.031 +KVM: 0.001 + +QEMU Intel HAX Windows + +Hi, + +Using the latest exe's from http://qemu.weilnetz.de/w32/ + +C:\Users\therock247uk\Desktop\jan\qemu-w64-setup-20170113>qemu-system-i386 --enable-hax -m 512 -cdrom C:\Users\therock247uk\Desktop\jan\en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso +HAX is working and emulator runs in fast virt mode. +Failed to allocate 20000000 memory + +The emulator seems to hang/get stuck during booting from the CD taking out --enable-hax allows it to boot. + +Which version were you exactly using? Can you still reproduce the problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/i386/1681398 b/results/classifier/118/i386/1681398 new file mode 100644 index 000000000..73fc44283 --- /dev/null +++ b/results/classifier/118/i386/1681398 @@ -0,0 +1,49 @@ +i386: 0.994 +device: 0.825 +TCG: 0.757 +graphic: 0.739 +x86: 0.672 +PID: 0.659 +semantic: 0.648 +architecture: 0.644 +network: 0.630 +socket: 0.598 +mistranslation: 0.583 +debug: 0.563 +ppc: 0.507 +kernel: 0.478 +vnc: 0.430 +register: 0.409 +performance: 0.400 +files: 0.379 +user-level: 0.371 +hypervisor: 0.368 +boot: 0.366 +peripherals: 0.342 +risc-v: 0.341 +arm: 0.334 +VMM: 0.278 +virtual: 0.269 +assembly: 0.190 +permissions: 0.182 +KVM: 0.135 + +hw/core: segmentation fault + +Reproducer: + $i386-softmmu/qemu-system-i386 -S -machine isapc,accel=tcg -device amd-iommu +Segmentation fault (core dumped) + +Partial bt: +#0 bus_add_child (child=0x555556d4e520, bus=0x0) at hw/core/qdev.c:88 +#1 qdev_set_parent_bus (dev=0x555556d4e520, bus=bus@entry=0x0) +at hw/core/qdev.c:119 + +This bug seems to have been fixed: we now report the command line issue with a more helpful message: + +$ qemu-system-i386 -S -machine isapc,accel=tcg -device amd-iommu +qemu-system-i386: -device amd-iommu: Machine-type 'isapc' not supported by IOMMU + +This was in QEMU 3.1, so I'm closing this bug. + + diff --git a/results/classifier/118/i386/1713328 b/results/classifier/118/i386/1713328 new file mode 100644 index 000000000..a5f2a3280 --- /dev/null +++ b/results/classifier/118/i386/1713328 @@ -0,0 +1,48 @@ +i386: 0.989 +x86: 0.965 +graphic: 0.896 +device: 0.883 +semantic: 0.798 +performance: 0.795 +peripherals: 0.772 +architecture: 0.764 +mistranslation: 0.738 +ppc: 0.736 +network: 0.703 +vnc: 0.647 +permissions: 0.616 +VMM: 0.559 +debug: 0.558 +TCG: 0.538 +user-level: 0.534 +register: 0.501 +PID: 0.492 +socket: 0.484 +kernel: 0.440 +risc-v: 0.407 +boot: 0.405 +virtual: 0.387 +arm: 0.374 +files: 0.324 +hypervisor: 0.286 +assembly: 0.226 +KVM: 0.222 + +Unable to C-a in -nographic if -serial telnet + +qemu-system-i386 (version 2.6.1, running on Linux/x86_64) started with: + +qemu-system-i386 -m 64M -machine type=pc -rtc base=localtime,clock=host -nographic -serial telnet:127.0.0.1:1234,server,nowait -net nic,model=ne2k_pci -net user,hostfwd=tcp:127.0.0.1:2200-:22,tftp=/ + +does not accept the escape key (C-a) to perform functions such as switching from monitor to console. Verified both in GNU screen and in the Linux console. + +If '-serial telnet:127.0.0.1:1234,server,nowait' is removed from the command line, the escape key is accepted (and Qemu doesn't enter the monitor immediately). + +Well, with your "-serial" setup, you've put the guest serial console on the telnet port, so there is nothing to switch on the host console here via the CTRL-a c key combination, i.e. this is the expected behavior. What exactly were you trying to do here? Access the serial console via two ways, one time via telnet and one time via the host console? AFAIK that's not possible. + +With '-serial telnet' I directed the serial port to telnet, not the console (I call "console" the VGA tty qemu would show without the -nographic option). + +Ah, ok, so you want to have the VGA output on the host console? Try the "-display curses" option for that. + +I tried it, but it doesn't really work well. Aside from showing 2 cursors, the real problem is that the keymap is all messed up in the guest (whereas it's perfect in Qemu's VGA monitor). + diff --git a/results/classifier/118/i386/1723488 b/results/classifier/118/i386/1723488 new file mode 100644 index 000000000..58d4840eb --- /dev/null +++ b/results/classifier/118/i386/1723488 @@ -0,0 +1,103 @@ +i386: 0.899 +graphic: 0.895 +performance: 0.885 +x86: 0.843 +boot: 0.837 +device: 0.801 +user-level: 0.791 +architecture: 0.787 +socket: 0.776 +semantic: 0.756 +files: 0.723 +vnc: 0.712 +PID: 0.709 +mistranslation: 0.671 +ppc: 0.667 +permissions: 0.650 +TCG: 0.638 +kernel: 0.635 +hypervisor: 0.631 +network: 0.586 +arm: 0.578 +debug: 0.548 +risc-v: 0.537 +register: 0.508 +assembly: 0.508 +VMM: 0.459 +virtual: 0.410 +peripherals: 0.395 +KVM: 0.321 + +HAX on Windows, memory lease error + +Today I tried to use QEMU on Windows 8.1 x64 with Intel HAX. + +Command line: qemu-system-x86_64.exe -accel hax -m 8000 -hda /opt/disk/ubuntu.img -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso + +Host machine has 32Gb physical memory, I got error: + +HAX is working and emulator runs in fast virt mode. +** +ERROR:A:/msys64/home/admin/git/qemu/target/i386/hax-mem.c:210:hax_process_section: assertion failed: (size <= UINT32_MAX) + +When using -m 4000 (and below) everything is fine. But if I try use >4000 and <8000 I get crash with errors: + +HAX is working and emulator runs in fast virt mode. +hax_transaction_commit: Failed mapping @0x0000000100000000+0x78800000 flags 00 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request + +It seems that HAX not working at all: + +qemu-system-x86_64.exe -accel hax -fda /opt/iso/freedos.img +(with image of boot floppy from official FreeDOS site) + +Crash on loading with: + +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request + +qemu-system-x86_64.exe -accel hax -cdrom /opt/iso/ubuntu-17.04-server-amd64.iso, hang on: + +Booting from DVD/CD... + +ISOLINUX 6.03 20170128 ETCD + +See https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows: + +"QEMU or Android Emulator will fail to launch if the guest RAM size (specified with the -m option for QEMU or -memory for Android Emulator) exceeds 4095MB." + +HAX is limited to a 32 bit memory size. There is no way to change that without breaking compatibility. + +The main problem is that HAX currently doesn't work properly at all on my both Windows 8.1 and Mac OS X 10.12.6 machines. +I can give other examples if it is necessary + +Looking through old bug tickets... is this still an 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/i386/1751494 b/results/classifier/118/i386/1751494 new file mode 100644 index 000000000..13a949ab9 --- /dev/null +++ b/results/classifier/118/i386/1751494 @@ -0,0 +1,55 @@ +i386: 0.883 +graphic: 0.676 +TCG: 0.641 +x86: 0.611 +assembly: 0.586 +device: 0.585 +semantic: 0.580 +files: 0.510 +mistranslation: 0.510 +architecture: 0.466 +user-level: 0.466 +performance: 0.417 +PID: 0.379 +socket: 0.335 +ppc: 0.334 +virtual: 0.331 +network: 0.320 +peripherals: 0.310 +hypervisor: 0.294 +permissions: 0.280 +vnc: 0.279 +debug: 0.258 +register: 0.247 +arm: 0.169 +risc-v: 0.165 +boot: 0.154 +VMM: 0.104 +kernel: 0.093 +KVM: 0.051 + +tcg-target.inc.c:3495:no such instruction: `xgetbv' + +While building QEMU on Mac OS 10.6.8 I saw this error message: +tag-target.inc.c:3495:no such instruction: `xgetbv' +In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: +asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); + +https://github.com/asmjit/asmjit/issues/78 +According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. + +Host info: +Mac OS 10.6.8 +GCC 5.2.0 + +Additional information: +This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. + +The exact commit that causes this problem is this: + +commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac +tcg/i386: Add vector operations + +This has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252 + diff --git a/results/classifier/118/i386/1783437 b/results/classifier/118/i386/1783437 new file mode 100644 index 000000000..e958e63d8 --- /dev/null +++ b/results/classifier/118/i386/1783437 @@ -0,0 +1,57 @@ +i386: 0.902 +graphic: 0.865 +ppc: 0.810 +x86: 0.716 +device: 0.715 +files: 0.686 +semantic: 0.684 +mistranslation: 0.634 +vnc: 0.625 +network: 0.617 +debug: 0.616 +socket: 0.609 +risc-v: 0.592 +register: 0.588 +performance: 0.574 +user-level: 0.538 +architecture: 0.525 +kernel: 0.511 +PID: 0.510 +VMM: 0.469 +boot: 0.466 +permissions: 0.437 +arm: 0.431 +virtual: 0.403 +TCG: 0.402 +hypervisor: 0.380 +peripherals: 0.375 +assembly: 0.337 +KVM: 0.209 + +read-modify-write page faults error code has write bit unset + +Consider the attached C file, which does a read-modify-write of the form `add [mem], reg`, where `mem` points to a non-present page. In the resulting page fault, the W/R bit is not set, while real hardware does set this bit. + +% gcc -m32 qemu-bug1.c&& ./a.out && qemu-i386 ./a.out +page fault: addr=0x70000000 err=0x6 +page fault: addr=0x70000000 err=0x4 + +Tested on the qemu-3.0.0-rc1 release. + + + +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/i386/1789751 b/results/classifier/118/i386/1789751 new file mode 100644 index 000000000..9dffd3f2f --- /dev/null +++ b/results/classifier/118/i386/1789751 @@ -0,0 +1,56 @@ +i386: 0.977 +x86: 0.890 +graphic: 0.817 +device: 0.791 +performance: 0.767 +semantic: 0.694 +PID: 0.687 +mistranslation: 0.623 +architecture: 0.618 +socket: 0.613 +network: 0.582 +boot: 0.572 +user-level: 0.569 +ppc: 0.519 +arm: 0.491 +virtual: 0.486 +kernel: 0.477 +register: 0.455 +debug: 0.422 +hypervisor: 0.398 +TCG: 0.389 +files: 0.379 +peripherals: 0.340 +permissions: 0.338 +VMM: 0.338 +vnc: 0.322 +risc-v: 0.266 +KVM: 0.247 +assembly: 0.246 + +Using -overcommit flag leads to qemu crashing + +Running the following leads to a qemu crash on startup: + +jwhite@laptop:~/os$ qemu-system-i386 -overcommit cpu-pm=on +qemu-system-i386: -overcommit cpu-pm=on: There is no option group 'overcommit' +Segmentation fault (core dumped) +jwhite@laptop:~/os$ + + +This fixes the issue: + +--- ../tmp/qemu-3.0.0/vl.c 2018-08-14 12:10:35.000000000 -0700 ++++ vl.c 2018-08-29 14:59:30.151554120 -0700 +@@ -2987,6 +2987,7 @@ + qemu_add_opts(&qemu_object_opts); + qemu_add_opts(&qemu_tpmdev_opts); + qemu_add_opts(&qemu_realtime_opts); ++ qemu_add_opts(&qemu_overcommit_opts); + qemu_add_opts(&qemu_msg_opts); + qemu_add_opts(&qemu_name_opts); + qemu_add_opts(&qemu_numa_opts); + +It seems to be fixed already: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1fdd4748711a62d863744 + diff --git a/results/classifier/118/i386/1830821 b/results/classifier/118/i386/1830821 new file mode 100644 index 000000000..b43794335 --- /dev/null +++ b/results/classifier/118/i386/1830821 @@ -0,0 +1,64 @@ +i386: 0.893 +KVM: 0.819 +device: 0.514 +graphic: 0.514 +architecture: 0.509 +network: 0.458 +hypervisor: 0.449 +performance: 0.446 +semantic: 0.411 +socket: 0.398 +ppc: 0.386 +permissions: 0.366 +vnc: 0.361 +risc-v: 0.358 +boot: 0.345 +register: 0.338 +arm: 0.337 +peripherals: 0.334 +virtual: 0.319 +VMM: 0.307 +x86: 0.296 +mistranslation: 0.287 +PID: 0.285 +files: 0.263 +user-level: 0.259 +TCG: 0.246 +kernel: 0.225 +debug: 0.164 +assembly: 0.150 + +Expose ARCH_CAP_MDS_NO in guest + +Description: + +MDS_NO is bit 5 of ARCH_CAPABILITIES. Expose this bit to guest. + +Target Qemu: 4.1 + +The specific upstream commit is 20140a82c67467f53814ca197403d5e1b561a5e5 and is incorporated into qemu 1:3.1+dfsg-2ubuntu3.1 in disco-security (19.04) and 1:3.1+dfsg-2ubuntu4 in eoan-proposed. For backporting to cosmic and older, I believe it requires the infrastructure to support IA32_ARCH_CAPABILITIES in place. + +This is done upstream, no need for the upstream bug task. +For Ubuntu I'll update the tasks to match the statement of sbeattie. +There are discussions to reconsider some of the backports, but unfortunately the IA32_ARCH_CAPABILITIES infrastructure is a rather big set of changes. + +This effort, if done, would be done together with: + +https://bugs.launchpad.net/intel/+bug/1828495 + +Please read comments: + +https://bugs.launchpad.net/intel/+bug/1828495/comments/8 + +and + +https://bugs.launchpad.net/intel/+bug/1828495/comments/10 + +I'm marking this bug as a duplicate of LP: #1828495 since both are asking for mitigations pass-through to i386 kvm guests and I'm preparing a fix for both simultaneously. + +Commit: + +https://bugs.launchpad.net/intel/+bug/1828495/comments/42 + +Addresses exactly this bug fix. + diff --git a/results/classifier/118/i386/1832 b/results/classifier/118/i386/1832 new file mode 100644 index 000000000..8d2e097b1 --- /dev/null +++ b/results/classifier/118/i386/1832 @@ -0,0 +1,31 @@ +i386: 0.969 +performance: 0.650 +register: 0.578 +device: 0.531 +user-level: 0.441 +architecture: 0.395 +semantic: 0.341 +mistranslation: 0.300 +arm: 0.293 +graphic: 0.265 +virtual: 0.215 +risc-v: 0.173 +assembly: 0.149 +TCG: 0.123 +PID: 0.122 +peripherals: 0.104 +vnc: 0.104 +boot: 0.104 +kernel: 0.086 +permissions: 0.083 +network: 0.067 +VMM: 0.051 +x86: 0.042 +socket: 0.027 +ppc: 0.027 +hypervisor: 0.020 +KVM: 0.018 +debug: 0.017 +files: 0.005 + +i386 test registers are not handled diff --git a/results/classifier/118/i386/1847906 b/results/classifier/118/i386/1847906 new file mode 100644 index 000000000..5a979bd1b --- /dev/null +++ b/results/classifier/118/i386/1847906 @@ -0,0 +1,68 @@ +i386: 0.916 +architecture: 0.735 +x86: 0.718 +graphic: 0.666 +device: 0.666 +performance: 0.628 +semantic: 0.577 +files: 0.525 +user-level: 0.510 +register: 0.502 +permissions: 0.488 +ppc: 0.477 +mistranslation: 0.476 +boot: 0.464 +PID: 0.458 +peripherals: 0.457 +network: 0.445 +debug: 0.443 +vnc: 0.423 +socket: 0.360 +risc-v: 0.333 +hypervisor: 0.317 +TCG: 0.313 +arm: 0.304 +kernel: 0.296 +VMM: 0.286 +virtual: 0.258 +KVM: 0.155 +assembly: 0.118 + +Cocoa display hangs on macOS 10.15 (Catalina) + +I have downloaded the latest stable source tarball 4.1.0 and compiled it (i386-softmmu target). + +After opening a black window, QEMU hangs (spinning beach ball). +When building with `--disable-cocoa --enable-sdl`, display seems to work fine. + +The same happened when I tried to build QEMU through HomeBrew and MacPorts. + +I am also affected by this after upgrading to 10.15 Catalina. + +I experience the same behavior using `qemu-system-x86_64`, but I can't confirm whether other systems are also affected. + +Building with SDL also fixed it for me so far: + +* `brew edit` +* add `depends_on "sdl2"` among other dependencies +* replace `--enable-cocoa` with `--disable-cocoa` +* replace `--disable-sdl` with `--enable-sdl` +* save, quit, and `brew install --build-from-source qemu` + +I tried with `--enable-gtk` and it hangs as well. +Using gtk3 build from MacPorts with `+quartz`. Now, this may be a systemwide problem with Gtk, I am yet to test other Gtk apps on Catalina. + +Investigation/patches would be welcome. Only one or two active upstream QEMU devs use OSX, and certainly personally I don't propose to upgrade to Catalina for at least six months to a year or so. + + +Hikaru Nishida kindly wrote a patch which should fix this: +https://<email address hidden>/ + + +This is wonderful! Thank you Peter and Hikaru for this patch. I will try it ASAP and confirm. + +Yes, works perfectly! + +Hikaru's patch is now in master as commit dff742ad27efa4, and will be in the next QEMU release. + + diff --git a/results/classifier/118/i386/1886210 b/results/classifier/118/i386/1886210 new file mode 100644 index 000000000..1da76bd22 --- /dev/null +++ b/results/classifier/118/i386/1886210 @@ -0,0 +1,55 @@ +i386: 0.914 +virtual: 0.818 +device: 0.734 +architecture: 0.651 +network: 0.577 +hypervisor: 0.557 +mistranslation: 0.545 +semantic: 0.532 +graphic: 0.516 +socket: 0.511 +VMM: 0.502 +PID: 0.446 +ppc: 0.418 +arm: 0.412 +files: 0.402 +permissions: 0.393 +register: 0.379 +vnc: 0.378 +kernel: 0.334 +user-level: 0.332 +boot: 0.281 +risc-v: 0.273 +performance: 0.263 +x86: 0.261 +debug: 0.216 +peripherals: 0.193 +TCG: 0.176 +KVM: 0.090 +assembly: 0.088 + +[Feature request] Illumnos VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +It would be useful to have a illumos VM to do build testing and avoid regressions. + +Suggested by Thomas Huth: +https://<email address hidden>/msg719202.html + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/258 + + diff --git a/results/classifier/118/i386/1891830 b/results/classifier/118/i386/1891830 new file mode 100644 index 000000000..b22876c50 --- /dev/null +++ b/results/classifier/118/i386/1891830 @@ -0,0 +1,73 @@ +i386: 0.934 +device: 0.815 +peripherals: 0.786 +x86: 0.721 +architecture: 0.710 +performance: 0.554 +PID: 0.532 +boot: 0.484 +network: 0.469 +mistranslation: 0.455 +kernel: 0.400 +register: 0.371 +permissions: 0.368 +ppc: 0.344 +socket: 0.337 +user-level: 0.331 +semantic: 0.324 +arm: 0.318 +hypervisor: 0.298 +graphic: 0.281 +VMM: 0.274 +risc-v: 0.273 +files: 0.271 +debug: 0.254 +vnc: 0.194 +TCG: 0.185 +virtual: 0.089 +KVM: 0.081 +assembly: 0.079 + +msmouse serial mouse emulation broken? No id byte sent on reset + +I took a shot at getting Windows 1.01 working. It doesn't support a PS/2 mouse out-of-the-box but does support MS serial mice. It doesn't seem to detect qemu's emulated msmouse. + +When I run this command: + +> qemu-system-i386 -nodefaults -hda my_windows1_hd.qcow2 -vga std -serial msmouse -trace enable='serial*' -icount shift=10,align=on + +I get this output (edited): + +251908@1597626456.800452:serial_ioport_write write addr 0x04 val 0x01 +251908@1597626456.800460:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.800462:serial_ioport_read read addr 0x00 val 0x00 + +[snip] + +251908@1597626456.961641:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961642:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961644:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961647:serial_ioport_write write addr 0x04 val 0x0b +251908@1597626456.961648:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961684:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961685:serial_ioport_read read addr 0x05 val 0x60 + +[snip] + +251908@1597626457.045894:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045895:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045897:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045932:serial_ioport_read read addr 0x00 val 0x00 + +The write of 0x01 and then 0x0b to reg 0x04 is the guest turning the RTS line off then on. A real mouse will respond to this by sending 0x4d, which is how the guest detects the mouse. + +Reproducible in current stable-4.2 and 5.0 (debian's build). I am able to get the guest to use a real passed-through serial mouse (with a minor hack, separate bug filed for this) + + +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/78 + + diff --git a/results/classifier/118/i386/1894029 b/results/classifier/118/i386/1894029 new file mode 100644 index 000000000..e5cd5fe8b --- /dev/null +++ b/results/classifier/118/i386/1894029 @@ -0,0 +1,74 @@ +i386: 0.969 +ppc: 0.837 +performance: 0.822 +peripherals: 0.809 +device: 0.754 +mistranslation: 0.696 +debug: 0.645 +graphic: 0.627 +assembly: 0.619 +user-level: 0.533 +architecture: 0.515 +PID: 0.485 +semantic: 0.449 +kernel: 0.395 +register: 0.353 +x86: 0.350 +vnc: 0.320 +permissions: 0.302 +arm: 0.292 +socket: 0.223 +network: 0.223 +boot: 0.221 +hypervisor: 0.213 +VMM: 0.202 +TCG: 0.186 +KVM: 0.173 +virtual: 0.158 +files: 0.153 +risc-v: 0.111 + +qemu-i386 malloc error + +Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong. +This is my test program: + +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, char **argv) +{ + void *pa=0,*pb=0,*pc=0,*pd=0; + pa = malloc(sizeof(uint32_t)); + pb = malloc(sizeof(uint32_t)); + pc = malloc(4); + pd = malloc(4); + printf("pa: 0x%x\n",pa); + printf("pb: 0x%x\n",pb); + printf("pc: 0x%x\n",pc); + printf("pd: 0x%x\n",pd); + printf("uint32_t:%d\n",sizeof(uint32_t)); + free(pa); + free(pb); + free(pc); + free(pd); + return 0; +} + +And it is wrong: + +pa: 0x400051a0 +pb: 0x400051b0 +pc: 0x400051c0 +pd: 0x400051d0 +uint32_t:4 + +Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes?? +Is it a BUG?? + +Please stop asking questions using a bug tracking system, this is rude. + +No it is not a bug, it appears you can't do simple arithmetics, -- the pointer is increased by 16 bytes not 2. + diff --git a/results/classifier/118/i386/1917184 b/results/classifier/118/i386/1917184 new file mode 100644 index 000000000..9ecfc4936 --- /dev/null +++ b/results/classifier/118/i386/1917184 @@ -0,0 +1,78 @@ +i386: 0.872 +user-level: 0.775 +x86: 0.734 +hypervisor: 0.636 +peripherals: 0.635 +architecture: 0.575 +device: 0.504 +network: 0.492 +kernel: 0.436 +ppc: 0.419 +performance: 0.398 +graphic: 0.393 +socket: 0.393 +semantic: 0.376 +PID: 0.369 +KVM: 0.364 +VMM: 0.362 +files: 0.339 +virtual: 0.322 +vnc: 0.311 +assembly: 0.293 +debug: 0.286 +risc-v: 0.272 +register: 0.261 +boot: 0.245 +mistranslation: 0.244 +permissions: 0.229 +TCG: 0.201 +arm: 0.198 + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip + +When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. + +qemu version 5.2.0, x86-64 host. + + + +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. + + +Bug still present in latest master + + +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/314 + + diff --git a/results/classifier/118/i386/2148 b/results/classifier/118/i386/2148 new file mode 100644 index 000000000..ffcf9f280 --- /dev/null +++ b/results/classifier/118/i386/2148 @@ -0,0 +1,39 @@ +i386: 0.968 +files: 0.845 +device: 0.826 +x86: 0.817 +graphic: 0.769 +network: 0.761 +semantic: 0.738 +architecture: 0.733 +socket: 0.645 +permissions: 0.629 +PID: 0.622 +VMM: 0.596 +mistranslation: 0.587 +user-level: 0.561 +kernel: 0.549 +risc-v: 0.511 +hypervisor: 0.497 +ppc: 0.495 +TCG: 0.480 +boot: 0.475 +arm: 0.466 +debug: 0.448 +peripherals: 0.402 +KVM: 0.395 +performance: 0.393 +register: 0.389 +vnc: 0.341 +virtual: 0.285 +assembly: 0.145 + +vdso.so is required to build vdso.so since 8.2.0 +Description of problem: +Removing binaries from the "source" distribution makes it unable to compile. It used to work in 8.1.4. +Steps to reproduce: +1. remove **/vdso.so +2. configure, build +3. `../linux-user/i386/meson.build:7:20: ERROR: File vdso.so does not exist.` +Additional information: +Build log in my Gentoo harness: [build.log](/uploads/da1933173b39dd6e5f9f90de09adc3a1/build.log) diff --git a/results/classifier/118/i386/2207 b/results/classifier/118/i386/2207 new file mode 100644 index 000000000..d38876253 --- /dev/null +++ b/results/classifier/118/i386/2207 @@ -0,0 +1,41 @@ +i386: 0.992 +graphic: 0.846 +debug: 0.815 +device: 0.791 +architecture: 0.786 +semantic: 0.719 +vnc: 0.663 +mistranslation: 0.640 +TCG: 0.618 +network: 0.540 +files: 0.504 +register: 0.492 +permissions: 0.489 +socket: 0.457 +virtual: 0.435 +kernel: 0.396 +ppc: 0.394 +arm: 0.379 +PID: 0.362 +VMM: 0.354 +risc-v: 0.348 +performance: 0.328 +boot: 0.326 +user-level: 0.316 +hypervisor: 0.234 +x86: 0.197 +peripherals: 0.152 +assembly: 0.128 +KVM: 0.062 + +WerFault.exe – Application Error. The memory could not be read in Win7 i386 +Description of problem: +WerFault Application Errors always occur when I open IE or even control panel. It's OK on QEMU 7.2 & 8.0 version according to my debug experience about qemu-system-i386 flavor in the last few months. +Steps to reproduce: +1. pulling _tag: v8.2.0_ code +2. emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3. just opening IE for maybe two or three times after the virtual machine has started +Additional information: +The error is displayed by Chinese. It says _WerFault.exe – Application Error. The instruction at 0x779f77b2 referenced memory at 0x6d0f6d20. The memory could not be read._ in English + + diff --git a/results/classifier/118/i386/2744 b/results/classifier/118/i386/2744 new file mode 100644 index 000000000..2739060a3 --- /dev/null +++ b/results/classifier/118/i386/2744 @@ -0,0 +1,35 @@ +i386: 0.960 +graphic: 0.800 +ppc: 0.730 +semantic: 0.660 +assembly: 0.644 +device: 0.602 +architecture: 0.598 +kernel: 0.573 +risc-v: 0.563 +x86: 0.523 +files: 0.510 +socket: 0.477 +network: 0.443 +mistranslation: 0.426 +vnc: 0.420 +register: 0.388 +performance: 0.371 +VMM: 0.362 +TCG: 0.353 +debug: 0.329 +permissions: 0.328 +boot: 0.302 +hypervisor: 0.265 +virtual: 0.248 +arm: 0.238 +peripherals: 0.218 +KVM: 0.198 +user-level: 0.179 +PID: 0.113 + +Avoid defining custom machine-definition macros for each new machine type +Additional information: +There are already some semi-generic implementations of this macro, such as [`DEFINE_PC_VER_MACHINE()`](https://gitlab.com/qemu-project/qemu/-/blob/aa3a285b5bc56a4208b3b57d4a55291e9c260107/include/hw/i386/pc.h#L326), which is used for the 'q35', 'pc' and 'isapc' machine types. + +There does appear to be some deviation from the template macro in some cases. We would have to enumerate what the nature of these deviations is, why only some machine types need them, and how they would fit into the proposed generic macro. Still, if we could have a generic macro that simplifies 80% of machine types' version definitions, then that seems like a win. diff --git a/results/classifier/118/i386/2845 b/results/classifier/118/i386/2845 new file mode 100644 index 000000000..13b5ea6f0 --- /dev/null +++ b/results/classifier/118/i386/2845 @@ -0,0 +1,62 @@ +i386: 0.847 +device: 0.812 +PID: 0.684 +performance: 0.678 +graphic: 0.662 +peripherals: 0.655 +ppc: 0.655 +virtual: 0.619 +socket: 0.566 +network: 0.547 +vnc: 0.537 +register: 0.536 +x86: 0.516 +VMM: 0.516 +kernel: 0.514 +architecture: 0.502 +files: 0.490 +arm: 0.485 +risc-v: 0.483 +hypervisor: 0.482 +TCG: 0.466 +boot: 0.461 +permissions: 0.445 +semantic: 0.418 +mistranslation: 0.369 +KVM: 0.339 +debug: 0.277 +user-level: 0.267 +assembly: 0.115 + +memory leak in virtio-pci devices +Description of problem: +The Use-After-Free bug mentioned by #2440 **has not been solved**, but the same crash is not reproducable in the later versions. After reviewing the code, I found an initiailized address space `proxy->modern_cfg_mem_as` introduced by [`55fa4be`](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html "Inspect Commit Details") in `virtio_pci@hw/virtio/virtio-pci.c` will not be destroyed if the later realization is failed. +This will cause memory leak of the device object, which has unused reference and will not be destroyed. + +Relative Code in `virtio_pci_realize@virtio-pci.c`: + +```c +/* subclasses can enforce modern, so do this unconditionally */ +memory_region_init(&proxy->modern_bar, OBJECT(proxy), "virtio-pci", + /* PCI BAR regions must be powers of 2 */ + pow2ceil(proxy->notify.offset + proxy->notify.size)); + +address_space_init(&proxy->modern_cfg_mem_as, &proxy->modern_bar, + "virtio-pci-cfg-mem-as"); + +if (proxy->disable_legacy == ON_OFF_AUTO_AUTO) { + proxy->disable_legacy = pcie_port ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF; +} +``` +Steps to reproduce: +```bash +cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0 +device_add virtio-net,failover=on,bus=br1,id=dev0 +quit +EOF +``` + +**This will cause UAF report in version `9.0.2`, but will not in `9.2.0`,** despite the bug still existing in code. +Additional information: +For ASAN report, please refer to #2440. diff --git a/results/classifier/118/i386/2899 b/results/classifier/118/i386/2899 new file mode 100644 index 000000000..99e8b3128 --- /dev/null +++ b/results/classifier/118/i386/2899 @@ -0,0 +1,66 @@ +i386: 0.888 +performance: 0.865 +graphic: 0.792 +TCG: 0.787 +kernel: 0.749 +device: 0.661 +files: 0.653 +ppc: 0.637 +architecture: 0.596 +semantic: 0.590 +debug: 0.582 +x86: 0.469 +socket: 0.443 +register: 0.437 +vnc: 0.425 +PID: 0.410 +user-level: 0.384 +network: 0.381 +hypervisor: 0.361 +arm: 0.306 +risc-v: 0.282 +boot: 0.229 +virtual: 0.213 +permissions: 0.207 +assembly: 0.138 +VMM: 0.135 +peripherals: 0.127 +KVM: 0.070 +mistranslation: 0.043 + +Regression 10.0.0rc1: Segmentation fault on executing QEMU advent calendar 2014, day 4 +Description of problem: +On executing QEMU, a segmentation fault occurs +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2014/download/stxmas.tar.xz +2. Execute with QEMU command line +Additional information: +git bisect finishes with: + +``` +456709db50f424d112bc5f07260fdc51555f3a24 is the first bad commit +commit 456709db50f424d112bc5f07260fdc51555f3a24 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Sun Dec 15 10:06:10 2024 +0100 + + target/i386: execute multiple REP/REPZ iterations without leaving TB + + Use a TCG loop so that it is not necessary to go through the setup steps + of REP and through the I/O check on every iteration. Interestingly, this + is not a particularly effective optimization on its own, though it avoids + the cost of correct RF emulation that was added in the previous patch. + The main benefit lies in allowing the hoisting of loop invariants outside + the loop, which will happen separately. + + The loop exits when the low 16 bits of CX/ECX/RCX are zero (so generally + speaking the string operation runs in 65536 iteration batches) to give + the main loop an opportunity to pick up interrupts. + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Link: https://lore.kernel.org/r/20241215090613.89588-12-pbonzini@redhat.com + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/translate.c | 55 ++++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 49 insertions(+), 6 deletions(-) +``` diff --git a/results/classifier/118/i386/302 b/results/classifier/118/i386/302 new file mode 100644 index 000000000..4f3c7b610 --- /dev/null +++ b/results/classifier/118/i386/302 @@ -0,0 +1,31 @@ +i386: 0.998 +performance: 0.870 +device: 0.849 +VMM: 0.770 +network: 0.698 +architecture: 0.661 +mistranslation: 0.661 +debug: 0.627 +graphic: 0.455 +peripherals: 0.372 +files: 0.288 +vnc: 0.252 +register: 0.250 +PID: 0.246 +permissions: 0.243 +x86: 0.239 +assembly: 0.223 +virtual: 0.217 +semantic: 0.216 +socket: 0.207 +boot: 0.154 +user-level: 0.120 +TCG: 0.083 +kernel: 0.047 +hypervisor: 0.015 +risc-v: 0.015 +ppc: 0.011 +KVM: 0.004 +arm: 0.003 + +[Fuzz] qemu-system-i386 virtio-mouse: Assertion in address_space_lduw_le_cached failed diff --git a/results/classifier/118/i386/363 b/results/classifier/118/i386/363 new file mode 100644 index 000000000..e569bc56e --- /dev/null +++ b/results/classifier/118/i386/363 @@ -0,0 +1,31 @@ +i386: 0.947 +device: 0.837 +architecture: 0.723 +debug: 0.571 +performance: 0.549 +x86: 0.504 +graphic: 0.496 +assembly: 0.360 +peripherals: 0.346 +hypervisor: 0.300 +boot: 0.276 +network: 0.256 +files: 0.248 +user-level: 0.222 +permissions: 0.209 +arm: 0.202 +mistranslation: 0.194 +virtual: 0.160 +kernel: 0.135 +semantic: 0.129 +PID: 0.125 +VMM: 0.099 +register: 0.097 +vnc: 0.076 +ppc: 0.065 +TCG: 0.040 +socket: 0.028 +risc-v: 0.026 +KVM: 0.012 + +Failed to build qemu-fuzz-i386 in version 6.0.0 diff --git a/results/classifier/118/i386/382 b/results/classifier/118/i386/382 new file mode 100644 index 000000000..f1fc4dbb0 --- /dev/null +++ b/results/classifier/118/i386/382 @@ -0,0 +1,31 @@ +i386: 0.991 +x86: 0.877 +mistranslation: 0.725 +semantic: 0.527 +files: 0.453 +architecture: 0.396 +graphic: 0.376 +device: 0.331 +debug: 0.204 +arm: 0.165 +performance: 0.129 +ppc: 0.121 +register: 0.119 +socket: 0.115 +assembly: 0.092 +boot: 0.085 +peripherals: 0.081 +vnc: 0.075 +user-level: 0.069 +network: 0.069 +TCG: 0.067 +virtual: 0.065 +VMM: 0.048 +risc-v: 0.037 +PID: 0.034 +permissions: 0.027 +hypervisor: 0.024 +KVM: 0.017 +kernel: 0.015 + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? diff --git a/results/classifier/118/i386/619 b/results/classifier/118/i386/619 new file mode 100644 index 000000000..8675a9dd5 --- /dev/null +++ b/results/classifier/118/i386/619 @@ -0,0 +1,31 @@ +i386: 0.992 +x86: 0.801 +TCG: 0.701 +performance: 0.701 +architecture: 0.504 +user-level: 0.416 +mistranslation: 0.415 +ppc: 0.354 +device: 0.342 +virtual: 0.309 +graphic: 0.308 +semantic: 0.223 +files: 0.198 +kernel: 0.147 +arm: 0.108 +hypervisor: 0.099 +KVM: 0.094 +debug: 0.085 +boot: 0.084 +VMM: 0.061 +vnc: 0.060 +register: 0.058 +network: 0.056 +risc-v: 0.056 +assembly: 0.042 +PID: 0.037 +peripherals: 0.030 +permissions: 0.023 +socket: 0.019 + +Move TCGCPUOps::fake_user_exception() to linux-user/i386/cpu_loop.c diff --git a/results/classifier/118/i386/662 b/results/classifier/118/i386/662 new file mode 100644 index 000000000..dda945f66 --- /dev/null +++ b/results/classifier/118/i386/662 @@ -0,0 +1,41 @@ +i386: 0.971 +device: 0.919 +graphic: 0.900 +files: 0.810 +peripherals: 0.780 +architecture: 0.692 +debug: 0.586 +network: 0.513 +vnc: 0.442 +boot: 0.440 +semantic: 0.438 +permissions: 0.416 +PID: 0.413 +ppc: 0.411 +register: 0.323 +socket: 0.319 +kernel: 0.307 +performance: 0.302 +VMM: 0.263 +arm: 0.249 +hypervisor: 0.220 +virtual: 0.209 +mistranslation: 0.194 +TCG: 0.180 +assembly: 0.123 +user-level: 0.107 +x86: 0.084 +risc-v: 0.077 +KVM: 0.007 + +Assertion `!s->do_cmd' failed in am53c974 emulator +Description of problem: + +Steps to reproduce: +``` +1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +2.make -j12 +3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img +``` +Additional information: +# diff --git a/results/classifier/118/i386/700276 b/results/classifier/118/i386/700276 new file mode 100644 index 000000000..4ac299212 --- /dev/null +++ b/results/classifier/118/i386/700276 @@ -0,0 +1,66 @@ +i386: 0.817 +kernel: 0.652 +debug: 0.641 +boot: 0.556 +graphic: 0.532 +x86: 0.459 +architecture: 0.443 +device: 0.391 +semantic: 0.382 +ppc: 0.302 +mistranslation: 0.246 +performance: 0.234 +socket: 0.219 +register: 0.173 +vnc: 0.162 +user-level: 0.144 +PID: 0.128 +network: 0.117 +files: 0.107 +risc-v: 0.096 +assembly: 0.074 +virtual: 0.073 +arm: 0.064 +hypervisor: 0.063 +TCG: 0.060 +permissions: 0.048 +peripherals: 0.046 +VMM: 0.038 +KVM: 0.026 + +QEMU crashed when GDB request a big size variable information + +Hello, +My host is Fedora 13. My QEMU version is 0.13.0, I use QEMU with GDB to debug Linux kernel(Version 2.6.36.2). + +I use QEMU like this:"qemu -s -S -kernel build/arch/i386/boot/bzImage -hda /dev/zero" +When GDB connected with QEMU, and use gdb command print to look big size variable, the qemu is crash down. for example, when I look a task_struct variable 'init_task'(print init_task ), the qemu produce the below message and exit. + +*** stack smashing detected ***: qemu terminated +======= Backtrace: ========= +/lib/libc.so.6(__fortify_fail+0x4d)[0x78a31d] +/lib/libc.so.6[0x78a2ca] +qemu[0x8059e21] +qemu[0x805a0cf] +qemu[0x80d12a1] +qemu[0x8189cb8] +qemu[0x818c3b0] +/lib/libc.so.6(__libc_start_main+0xe6)[0x6a8cc6] +............... +adbf7000-adbf8000 rw-p 00000000 00:00 0 +adbf8000-ae3f8000 rw-p 00000000 00:00 0 +ae3f8000-ae742000 rw-p 00000000 00:00 0 +ae742000-ae762000 rw-p 00000000 00:00 0 +ae762000-ae764000 rw-p 00000000 00:00 0 +ae764000-ae784000 rw-p 00000000 00:00 0 +ae784000-ae786000 rw-p 00000000 00:00 0 +ae786000-b6786000 rw-p 00000000 00:00 0 +b6786000-b7894000 rw-p 00000000 00:00 0 +b78aa000-b78ab000 rw-p 00000000 00:00 0 +bfe95000-bfeaa000 rw-p 00000000 00:00 0 [stack] +已放弃 (core dumped) + +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/i386/855630 b/results/classifier/118/i386/855630 new file mode 100644 index 000000000..f45c2164f --- /dev/null +++ b/results/classifier/118/i386/855630 @@ -0,0 +1,61 @@ +i386: 0.853 +user-level: 0.784 +semantic: 0.773 +arm: 0.753 +ppc: 0.745 +architecture: 0.741 +PID: 0.700 +x86: 0.693 +files: 0.685 +graphic: 0.652 +mistranslation: 0.602 +performance: 0.531 +device: 0.512 +vnc: 0.498 +socket: 0.418 +kernel: 0.416 +register: 0.406 +hypervisor: 0.390 +virtual: 0.361 +network: 0.337 +boot: 0.331 +TCG: 0.324 +risc-v: 0.324 +VMM: 0.306 +permissions: 0.301 +debug: 0.276 +peripherals: 0.247 +assembly: 0.226 +KVM: 0.150 + +Cant Run Wine (posix not nptl) past 0.14.1 + +when trying to build qemu I can build with ./configure --static --enable-sdl --target-list=i386-linux-user just fine with 0.12.5 + +But when I try to go on 0.13.0 or higher (tested on 0.15.0) it will say it cant find libSDL. + +Tried with arm and x86 versions of Ubuntu 9.10 and 11.04. Same on all 4 tests. + +I found I could run posix wine on 12.5 but I cant go higher for posix wine because of that libSDL. + +Oh I forgot to mention, you can compile qemu 0.13.0 or higher without the --static, and with --enable-sdl just fine all the way up to 0.15.5 + +But with --static, it cant find libSDL. + +0.12.5 Can do this just fine. It can do --static --enable-sdl together, and find my libSDL, and run posix wine. + +SDL is only of any use for the system emulation targets. If you're just building a linux-user target there is no point passing --enable-sdl to configure. Just use "./configure --static --target-list=i386-linux-user". + + +Thanks! Your right I disabled SDL and wine posix still worked on 12.5.. but not on 13.0 or higher.. I thought SDL was the reason why. ??? =) + +Wine posix isnt fun to get. http://www.onsitedentalsystems.com/wine.tar.gz + +the binary files in there run fine for qemu-i386 0.12.5 but nothing higher then that.. I dont know why. + +Triaging old bug tickets... The problem with the SDL static linking has likely been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5f37e6d4a7b22ccf1bb8fa4 +Can you still reproduce the other 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.] + |