diff options
Diffstat (limited to 'results/classifier/118/architecture-x86')
47 files changed, 4084 insertions, 0 deletions
diff --git a/results/classifier/118/architecture-x86/1004408 b/results/classifier/118/architecture-x86/1004408 new file mode 100644 index 000000000..8e4acfd54 --- /dev/null +++ b/results/classifier/118/architecture-x86/1004408 @@ -0,0 +1,99 @@ +x86: 0.938 +graphic: 0.919 +KVM: 0.867 +vnc: 0.834 +kernel: 0.833 +architecture: 0.816 +device: 0.797 +performance: 0.763 +debug: 0.755 +user-level: 0.740 +mistranslation: 0.719 +semantic: 0.685 +peripherals: 0.669 +socket: 0.612 +PID: 0.601 +risc-v: 0.583 +ppc: 0.581 +permissions: 0.550 +arm: 0.543 +boot: 0.504 +network: 0.490 +VMM: 0.488 +TCG: 0.482 +hypervisor: 0.395 +register: 0.388 +assembly: 0.368 +i386: 0.359 +virtual: 0.350 +files: 0.345 +-------------------- +x86: 0.998 +KVM: 0.958 +debug: 0.905 +virtual: 0.792 +hypervisor: 0.772 +kernel: 0.736 +performance: 0.192 +PID: 0.178 +TCG: 0.119 +register: 0.050 +graphic: 0.047 +vnc: 0.047 +files: 0.029 +device: 0.023 +architecture: 0.023 +socket: 0.019 +semantic: 0.018 +VMM: 0.017 +boot: 0.016 +i386: 0.010 +user-level: 0.008 +assembly: 0.008 +peripherals: 0.006 +network: 0.006 +risc-v: 0.004 +permissions: 0.003 +ppc: 0.002 +mistranslation: 0.001 +arm: 0.000 + +BUG: Soft Lockup - CPU#0 stuck for 22s! [qemu-system-x86: 31867] + +Environment: +------------------- + * Upstream git version: qemu-kvm-1.1-rc2-4-g3fd9fed + * Host Kernel: Mainline Kernel - 3.4.0 x86_64 GNU/Linux (Arch: x86_64) + * CPU model: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz + * Guest OS: Red Hat Enterprise Linux Server release 6.2 + * Guest Kernel: 2.6.32-220.el6.x86_64 + * Qemu-command line: +/usr/local/bin/qemu-system-x86_64 -name 'vm1' -nodefaults -monitor unix:'/tmp/monitor-humanmonitor1-20120525-214210-Zua6',server,nowait -serial unix:'/tmp/serial-20120525-214210-Zua6',server,nowait -device ich9-usb-uhci1,id=usb1 -drive file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',index=0,if=ide,cache=none -device rtl8139,netdev=idvVySvg,mac='9a:6d:16:b9:b5:06',id='idiX1NmG' -netdev tap,id=idvVySvg,fd=21 -m 7198 -smp 2 -device usb-tablet,id=usb-tablet1,bus=usb1.0 -vnc :0 -vga std + +The qemu is started through autotest. + +Description: +----------------- + +While running the cgroup test through autotest, the host was hung and was not responding. When viewed through serial console, found the error "BUG: Soft lockup" error as attached in the screenshot 1. + +There are no errors displayed in /var/log/messages (no call trace) and in dmesg.* +There is a call trace seen in serial console, which is show in screenshot 2. + +Steps to reproduce: +---------------------------- +Currently am not able to consistently reproduce this error. However when I tried to reproduce it again by running the cgroup test, found another error from syslogd as shown below + +"Message from syslogd@phx3 at May 25 21:56:04 ... + kernel:Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 3" + +So this time I got a hard Lockup error. Attached is the screenshot of the same. (screenshot-3, see the message at the bottom of the screen). This time the cgroup test had completed. + +Please let me know if you require more info on this. + +-prem + + + +Thanks for the bug report, but please report kernel bugs in the kernel bug tracker, not in the QEMU bug tracker (see http://www.linux-kvm.org/page/Bugs for details). So if the problem still persists with recent kernels, you should open a ticket there instead. + diff --git a/results/classifier/118/architecture-x86/1011 b/results/classifier/118/architecture-x86/1011 new file mode 100644 index 000000000..bbdd3b5c6 --- /dev/null +++ b/results/classifier/118/architecture-x86/1011 @@ -0,0 +1,81 @@ +x86: 0.947 +architecture: 0.814 +kernel: 0.798 +device: 0.789 +graphic: 0.772 +vnc: 0.706 +semantic: 0.601 +ppc: 0.591 +user-level: 0.478 +hypervisor: 0.413 +network: 0.400 +performance: 0.364 +socket: 0.356 +files: 0.347 +PID: 0.344 +debug: 0.332 +register: 0.321 +i386: 0.307 +permissions: 0.247 +arm: 0.236 +mistranslation: 0.227 +peripherals: 0.223 +VMM: 0.211 +TCG: 0.206 +boot: 0.201 +virtual: 0.178 +risc-v: 0.101 +assembly: 0.094 +KVM: 0.061 +-------------------- +x86: 0.993 +hypervisor: 0.943 +kernel: 0.760 +debug: 0.756 +virtual: 0.703 +TCG: 0.051 +files: 0.044 +register: 0.032 +PID: 0.023 +socket: 0.019 +KVM: 0.019 +device: 0.017 +performance: 0.013 +VMM: 0.008 +network: 0.006 +architecture: 0.006 +assembly: 0.005 +user-level: 0.005 +semantic: 0.004 +i386: 0.003 +boot: 0.003 +ppc: 0.002 +risc-v: 0.002 +peripherals: 0.002 +permissions: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +hvf: RDTSCP capability not passed to guests +Description of problem: + +Steps to reproduce: +1. Run: +wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso +./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso + +2. login as "root" +3. type + +cat /etc/cpuinfo | grep rdtscp + +Expected result: cpu flag lines including rdtscp +Actual result: empty, with: + +warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27] +Additional information: +This patch apparently resolves the issue according to my tests: + +https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/ diff --git a/results/classifier/118/architecture-x86/1042561 b/results/classifier/118/architecture-x86/1042561 new file mode 100644 index 000000000..f41010032 --- /dev/null +++ b/results/classifier/118/architecture-x86/1042561 @@ -0,0 +1,97 @@ +x86: 0.918 +kernel: 0.833 +architecture: 0.800 +KVM: 0.794 +device: 0.721 +performance: 0.621 +PID: 0.595 +ppc: 0.573 +network: 0.531 +graphic: 0.525 +semantic: 0.460 +socket: 0.448 +hypervisor: 0.447 +i386: 0.442 +peripherals: 0.420 +boot: 0.388 +risc-v: 0.385 +VMM: 0.384 +vnc: 0.373 +user-level: 0.373 +arm: 0.371 +mistranslation: 0.339 +permissions: 0.336 +virtual: 0.306 +files: 0.298 +TCG: 0.281 +register: 0.279 +debug: 0.232 +assembly: 0.230 +-------------------- +KVM: 0.943 +TCG: 0.926 +register: 0.891 +virtual: 0.839 +kernel: 0.822 +hypervisor: 0.807 +PID: 0.669 +x86: 0.611 +debug: 0.476 +socket: 0.234 +boot: 0.126 +files: 0.118 +risc-v: 0.116 +semantic: 0.075 +performance: 0.016 +architecture: 0.016 +device: 0.014 +permissions: 0.006 +assembly: 0.006 +peripherals: 0.004 +network: 0.004 +i386: 0.003 +user-level: 0.003 +VMM: 0.002 +graphic: 0.002 +vnc: 0.002 +ppc: 0.002 +mistranslation: 0.001 +arm: 0.001 + +Guest has no "xsave" feature with parameter "-cpu qemu64,+xsave" in qemu command line. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:1a577b72475d161b6677c05abe57301362023bb2 +qemu-kvm Commit:98f1f30a89901c416e51cc70c1a08d9dc15a2ad4 +Host Kernel Version:3.5.0-rc1 +Hardware:Romley-EP, Ivy-bridge + + +Bug detailed description: +-------------------------- +Guest has no "xsave" feature when create guest with parameter "-cpu qemu64,+xsave,+avx" in qemu command line, but the guest has avx feature. +When starting a guest with parameter "-cpu host" in qemu command line, the guest has 'avx' and 'xsave' features (as /proc/cpuinfo shows). + +This is not a recent regression; it exists for a long time. + +Reproduce steps: +---------------- +1. qemu-system-x86_64 -m 1024 -smp 2 -hda rhel6u3.img -cpu qemu64,+xsave +2. cat /proc/cpuinfo | grep xsave ( check guest's xsave feature) + +Current result: +---------------- +The guest has no xsave feature + +Expected result: +---------------- +The guest has xsave feature + +Basic root-causing log: + +xsave needs level >= 13, and qemu64 has level=4. Try "-cpu qemu64,+xsave,+avx,level=13". + diff --git a/results/classifier/118/architecture-x86/1195012 b/results/classifier/118/architecture-x86/1195012 new file mode 100644 index 000000000..a4f809e4a --- /dev/null +++ b/results/classifier/118/architecture-x86/1195012 @@ -0,0 +1,100 @@ +x86: 0.942 +i386: 0.935 +architecture: 0.922 +performance: 0.853 +user-level: 0.820 +graphic: 0.772 +semantic: 0.752 +network: 0.716 +device: 0.688 +ppc: 0.677 +mistranslation: 0.655 +register: 0.594 +kernel: 0.594 +socket: 0.582 +PID: 0.576 +files: 0.558 +hypervisor: 0.533 +virtual: 0.530 +boot: 0.527 +vnc: 0.518 +TCG: 0.467 +permissions: 0.453 +peripherals: 0.448 +debug: 0.444 +risc-v: 0.435 +VMM: 0.433 +arm: 0.400 +KVM: 0.382 +assembly: 0.284 +-------------------- +x86: 0.933 +architecture: 0.711 +i386: 0.662 +kernel: 0.547 +virtual: 0.441 +performance: 0.413 +debug: 0.264 +TCG: 0.056 +files: 0.033 +hypervisor: 0.025 +PID: 0.021 +register: 0.010 +risc-v: 0.009 +VMM: 0.008 +network: 0.007 +socket: 0.005 +device: 0.005 +user-level: 0.004 +boot: 0.003 +vnc: 0.003 +semantic: 0.003 +assembly: 0.002 +ppc: 0.002 +peripherals: 0.001 +permissions: 0.001 +arm: 0.001 +graphic: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +x86_64 and i386 return 0 when reading MSR_TSC + +Running NetBSD 6.1 (i386 and amd64) under QEMU (from git - 1.5.50 is the version it shows) results in an incorrectly set +TSC frequency (set to 0), because NetBSD uses rdmsr(TSC_MSR) for its serializing CPU counter. + +To reproduce the problem, you can run an install ISO of NetBSD 6.1 (either i386 or amd64, depending on which qemu). Quit out of the installer, and you're left at a root prompt: + +# sysctl machdep.tsc_freq +machdep.tsc_freq = 0 + +...on real hardware, it will return the TSC frequency: + +# sysctl machdep.tsc_freq +machdep.tsc_freq = 3292685070 + +...this causes problems with a number of applications. + +The NetBSD code which reads the MSR is here: + +http://nxr.netbsd.org/xref/src/sys/arch/x86/x86/tsc.c#262 + +... the "rdmsr(MSR_TSC)" call in cpu_counter_serializing() always returns 0 when run under QEMU. + +I should mention, the NetBSD 6.1 ISO I used for testing is here: + +http://iso.netbsd.org/pub/NetBSD/iso/6.1/NetBSD-6.1-amd64.iso + + + +The NetBSD problem report where this issue was raised: + +http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=47967 + +a workaround has been put in place for now, but it would be good to fix this in QEMU. + +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/architecture-x86/1245543 b/results/classifier/118/architecture-x86/1245543 new file mode 100644 index 000000000..379d3e1f4 --- /dev/null +++ b/results/classifier/118/architecture-x86/1245543 @@ -0,0 +1,90 @@ +x86: 0.966 +architecture: 0.948 +performance: 0.804 +device: 0.770 +kernel: 0.743 +ppc: 0.659 +register: 0.630 +semantic: 0.629 +socket: 0.619 +peripherals: 0.587 +i386: 0.582 +network: 0.548 +vnc: 0.529 +PID: 0.521 +permissions: 0.498 +graphic: 0.455 +boot: 0.437 +mistranslation: 0.417 +VMM: 0.414 +risc-v: 0.404 +user-level: 0.403 +hypervisor: 0.395 +TCG: 0.382 +debug: 0.381 +files: 0.344 +arm: 0.295 +assembly: 0.269 +KVM: 0.262 +virtual: 0.207 +-------------------- +x86: 0.965 +debug: 0.520 +TCG: 0.455 +virtual: 0.150 +hypervisor: 0.106 +kernel: 0.054 +PID: 0.038 +files: 0.036 +register: 0.033 +user-level: 0.011 +assembly: 0.011 +socket: 0.010 +performance: 0.007 +network: 0.007 +boot: 0.005 +architecture: 0.004 +device: 0.004 +semantic: 0.003 +vnc: 0.003 +risc-v: 0.002 +peripherals: 0.002 +graphic: 0.002 +VMM: 0.001 +ppc: 0.001 +permissions: 0.001 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 +KVM: 0.000 + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" + + + +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/architecture-x86/125 b/results/classifier/118/architecture-x86/125 new file mode 100644 index 000000000..846ba5f62 --- /dev/null +++ b/results/classifier/118/architecture-x86/125 @@ -0,0 +1,61 @@ +x86: 0.995 +architecture: 0.931 +device: 0.803 +network: 0.776 +kernel: 0.621 +performance: 0.608 +arm: 0.586 +boot: 0.421 +risc-v: 0.404 +peripherals: 0.378 +socket: 0.347 +mistranslation: 0.326 +VMM: 0.306 +debug: 0.281 +files: 0.262 +graphic: 0.250 +register: 0.188 +TCG: 0.182 +assembly: 0.160 +permissions: 0.157 +semantic: 0.144 +PID: 0.130 +vnc: 0.111 +hypervisor: 0.100 +ppc: 0.057 +virtual: 0.036 +i386: 0.022 +KVM: 0.020 +user-level: 0.017 +-------------------- +x86: 0.999 +i386: 0.982 +assembly: 0.975 +debug: 0.264 +architecture: 0.053 +kernel: 0.016 +TCG: 0.014 +virtual: 0.009 +semantic: 0.006 +files: 0.005 +device: 0.004 +performance: 0.003 +VMM: 0.003 +graphic: 0.003 +risc-v: 0.002 +user-level: 0.002 +PID: 0.002 +KVM: 0.002 +boot: 0.001 +mistranslation: 0.001 +network: 0.001 +register: 0.001 +socket: 0.001 +hypervisor: 0.001 +permissions: 0.001 +peripherals: 0.000 +vnc: 0.000 +ppc: 0.000 +arm: 0.000 + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack diff --git a/results/classifier/118/architecture-x86/1252010 b/results/classifier/118/architecture-x86/1252010 new file mode 100644 index 000000000..571bf933a --- /dev/null +++ b/results/classifier/118/architecture-x86/1252010 @@ -0,0 +1,76 @@ +x86: 0.939 +device: 0.891 +architecture: 0.831 +graphic: 0.828 +virtual: 0.775 +boot: 0.754 +PID: 0.694 +VMM: 0.683 +mistranslation: 0.647 +performance: 0.632 +ppc: 0.628 +vnc: 0.624 +semantic: 0.595 +hypervisor: 0.504 +risc-v: 0.504 +arm: 0.456 +register: 0.372 +socket: 0.358 +permissions: 0.352 +debug: 0.327 +user-level: 0.322 +assembly: 0.305 +network: 0.258 +kernel: 0.257 +KVM: 0.238 +TCG: 0.224 +i386: 0.218 +files: 0.167 +peripherals: 0.105 +-------------------- +x86: 0.996 +virtual: 0.924 +i386: 0.517 +hypervisor: 0.478 +performance: 0.425 +debug: 0.400 +user-level: 0.048 +TCG: 0.039 +PID: 0.015 +files: 0.011 +device: 0.008 +socket: 0.008 +register: 0.008 +network: 0.006 +architecture: 0.006 +semantic: 0.004 +kernel: 0.003 +assembly: 0.003 +risc-v: 0.002 +VMM: 0.001 +ppc: 0.001 +boot: 0.001 +arm: 0.001 +peripherals: 0.001 +permissions: 0.001 +graphic: 0.001 +vnc: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +can't assign enough RAM to the VM + +QEMU version: 1.6.90.0 from 2013 11 16 +Host OS: Windows XP SP3 x86 +Host machine: 3.2 GHz AMD Athlon 64 dual core processor, 4 GB DDR II (3.2 seen by the OS) memory +Guest OS: Grub4Dos boot manager menu +Problem: you can't assign more than 880 MB memory to the VM, although with 0.15.1.0 version you can assign up to 1179 MB. + +QEMU currently needs contiguous memory for the guest memory. Hosts running 32 bit Windows only provide about 2 GiB for programs. This 2 GiB is used for the executable, all loaded dlls and dynamic memory. Especially the dlls cause memory fragmentation, so newer versions of QEMU which need more dlls get less contiguous memory. + +Running 32 bit QEMU on 64 bit Windows helps, and 64 bit QEMU also has no problem with allocating a large guest RAM. + +Could we close this bug now - I think most people are using 64-bit host systems nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-x86/1272796 b/results/classifier/118/architecture-x86/1272796 new file mode 100644 index 000000000..3555b2151 --- /dev/null +++ b/results/classifier/118/architecture-x86/1272796 @@ -0,0 +1,86 @@ +x86: 0.954 +i386: 0.901 +architecture: 0.880 +performance: 0.825 +graphic: 0.810 +boot: 0.802 +device: 0.787 +ppc: 0.786 +peripherals: 0.775 +semantic: 0.726 +user-level: 0.697 +PID: 0.661 +files: 0.657 +virtual: 0.649 +socket: 0.631 +mistranslation: 0.613 +kernel: 0.567 +arm: 0.555 +register: 0.538 +vnc: 0.533 +hypervisor: 0.519 +assembly: 0.498 +risc-v: 0.487 +permissions: 0.474 +VMM: 0.473 +KVM: 0.449 +network: 0.421 +TCG: 0.419 +debug: 0.326 +-------------------- +x86: 0.998 +i386: 0.998 +virtual: 0.889 +debug: 0.232 +user-level: 0.138 +boot: 0.018 +files: 0.009 +TCG: 0.006 +PID: 0.005 +hypervisor: 0.004 +network: 0.004 +performance: 0.004 +VMM: 0.003 +device: 0.002 +register: 0.002 +socket: 0.002 +semantic: 0.001 +vnc: 0.001 +assembly: 0.001 +kernel: 0.001 +risc-v: 0.001 +peripherals: 0.001 +graphic: 0.001 +architecture: 0.000 +permissions: 0.000 +ppc: 0.000 +mistranslation: 0.000 +KVM: 0.000 +arm: 0.000 + +Windows 98 First Edition emulation problems + +System: Debian SID x86 with latest updates + +1) QEMU compiled from latest main GIT branch (and 1.7 stable version) +./configure options: ./configure --enable-sdl --target-list=i386-softmmu --cpu=i686 --audio-drv-list=alsa + +When you try to boot Windows 98 First Edition (Italian), it does not simply boot. It stays on booting screen. +If you try to install, the installation goes flawless, but when it boots it freeze. + +I am launching VM with this: qemu-system-i386 -hda main.img -cpu pentium -m 256 -fda floppy1.img -boot c -soundhw gus -vga cirrus + +I have tried with -M option "pc-i440fx-1.6" since 1.6 have no problems with the booting of Win98, but nothing. No fix found. + +2) QEMU 1.6.2 (same compile and launching options) +gus soundboard seems not recognized even with real dos drivers (tried to install theme into real dos mode). +with SoundBlaster 16 i have following error: WARNING: I/O thread spun for 1000 iterations, making the emulation impossible (too slow, and sound is stuttering) . Tried to compile with oss and sdl option on audio-drv-list but no fix found. + +Any ideas? thank you + +Even with Windows 98 SE (English and Italian) still not working. Got some ideas? + +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/architecture-x86/1294 b/results/classifier/118/architecture-x86/1294 new file mode 100644 index 000000000..e069d7b49 --- /dev/null +++ b/results/classifier/118/architecture-x86/1294 @@ -0,0 +1,61 @@ +x86: 0.947 +architecture: 0.905 +device: 0.858 +network: 0.795 +files: 0.669 +arm: 0.588 +performance: 0.501 +register: 0.433 +graphic: 0.389 +boot: 0.372 +i386: 0.295 +risc-v: 0.269 +TCG: 0.268 +debug: 0.254 +semantic: 0.241 +socket: 0.234 +hypervisor: 0.193 +virtual: 0.188 +VMM: 0.161 +peripherals: 0.157 +PID: 0.145 +vnc: 0.138 +kernel: 0.132 +ppc: 0.100 +user-level: 0.084 +mistranslation: 0.064 +assembly: 0.046 +permissions: 0.038 +KVM: 0.008 +-------------------- +x86: 0.998 +peripherals: 0.431 +assembly: 0.106 +i386: 0.096 +files: 0.071 +debug: 0.070 +user-level: 0.060 +virtual: 0.058 +kernel: 0.053 +device: 0.033 +semantic: 0.011 +PID: 0.005 +TCG: 0.004 +register: 0.004 +architecture: 0.004 +socket: 0.003 +hypervisor: 0.003 +boot: 0.002 +performance: 0.002 +ppc: 0.002 +graphic: 0.002 +VMM: 0.001 +risc-v: 0.001 +permissions: 0.001 +network: 0.001 +KVM: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +pflash size check appears to be incompatible with OVMF on x86 diff --git a/results/classifier/118/architecture-x86/1376 b/results/classifier/118/architecture-x86/1376 new file mode 100644 index 000000000..ea92a7e5b --- /dev/null +++ b/results/classifier/118/architecture-x86/1376 @@ -0,0 +1,75 @@ +x86: 0.998 +architecture: 0.974 +assembly: 0.897 +device: 0.854 +i386: 0.835 +graphic: 0.701 +vnc: 0.674 +socket: 0.609 +kernel: 0.586 +ppc: 0.577 +performance: 0.549 +debug: 0.535 +peripherals: 0.533 +permissions: 0.525 +risc-v: 0.525 +network: 0.505 +boot: 0.489 +semantic: 0.444 +arm: 0.434 +register: 0.394 +PID: 0.269 +files: 0.263 +KVM: 0.243 +VMM: 0.227 +hypervisor: 0.207 +TCG: 0.194 +mistranslation: 0.191 +virtual: 0.155 +user-level: 0.143 +-------------------- +x86: 1.000 +i386: 0.973 +assembly: 0.954 +debug: 0.615 +semantic: 0.359 +register: 0.334 +performance: 0.090 +TCG: 0.078 +architecture: 0.053 +kernel: 0.052 +virtual: 0.045 +files: 0.044 +user-level: 0.020 +hypervisor: 0.014 +device: 0.011 +PID: 0.010 +boot: 0.009 +peripherals: 0.008 +network: 0.008 +risc-v: 0.004 +permissions: 0.003 +graphic: 0.002 +socket: 0.002 +ppc: 0.001 +VMM: 0.001 +vnc: 0.001 +mistranslation: 0.000 +KVM: 0.000 +arm: 0.000 + +x86 LSL and LAR fault +Description of problem: +From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xa02e698e741f5a6a"); + asm("mov rbx, 0x20959ddd7a0aef"); + asm("lsl ax, bx"); +} +``` +2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/118/architecture-x86/1502095 b/results/classifier/118/architecture-x86/1502095 new file mode 100644 index 000000000..2e7218b12 --- /dev/null +++ b/results/classifier/118/architecture-x86/1502095 @@ -0,0 +1,104 @@ +x86: 0.985 +architecture: 0.933 +virtual: 0.890 +debug: 0.887 +performance: 0.877 +network: 0.866 +device: 0.747 +graphic: 0.736 +peripherals: 0.734 +mistranslation: 0.713 +VMM: 0.684 +KVM: 0.650 +hypervisor: 0.632 +kernel: 0.625 +PID: 0.615 +semantic: 0.589 +ppc: 0.541 +user-level: 0.535 +register: 0.484 +files: 0.454 +socket: 0.429 +arm: 0.363 +assembly: 0.320 +vnc: 0.318 +risc-v: 0.277 +i386: 0.275 +TCG: 0.265 +boot: 0.237 +permissions: 0.211 +-------------------- +virtual: 0.994 +debug: 0.983 +x86: 0.982 +user-level: 0.643 +hypervisor: 0.483 +TCG: 0.134 +kernel: 0.097 +KVM: 0.074 +VMM: 0.029 +files: 0.020 +register: 0.017 +PID: 0.017 +semantic: 0.009 +performance: 0.007 +architecture: 0.004 +network: 0.004 +device: 0.004 +socket: 0.003 +risc-v: 0.002 +graphic: 0.002 +peripherals: 0.002 +boot: 0.002 +assembly: 0.002 +permissions: 0.001 +ppc: 0.001 +vnc: 0.001 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +Sporadic input / output error — x86-64 linux guest + +** Setup: ** + +→ Host + Qemu version 2.4.0.1 + Linux: 4.1.1 (Debian 8.2, GCC 4.9.2, x86_64) + filesystem ext3 and ext4 + +→ Guests (3 VMs) + architecture x86_64, Linux 3.16.0-4-amd64 (Debian 7.6) + virtual disk qcow2, uncompressed + guests filesystem ext3 + virtual disks size: VM1: 3GB, VM2: 5GB, VM3: 250GB + +→ Network + bridge (br0) and tap interfaces. + + +** Command line ** + +For all 3 VMs, the command line is similar to the following. Only RAM size and ID ("109") are changed. + + /usr/local/bin/qemu-system-x86_64 -hda /media/raid1/qemu-109 -m 8G -smp 4 -enable-kvm \ + -netdev bridge,id=br109 -device virtio-net-pci,netdev=br109,id=nic0,mac=00:00:00:00:01:09 \ + -k it -daemonize + + +** Problem ** + +Sporadic, unexplained input output error. +When I try to SSH to one of the instances, most of the times everything just works fine. Some other times, the SSH connection can be established, but as I interact with the guests via SSH (ls, cd, top) the guest reports "input / output error" on the SSH console. Sometimes, the SSH daemon on the guest answers "/bin/bash input output error". Sometimes the SSH client answers that the connection has been dropped by the host. + +When this happens, the web services I run on the VMs get unreachable, the VMs themselves are unreachable/unusable via SSH as described, and after killing the relative qemu processes and restarting the VMs, no recent logs are registered on /var/logs, arguably since the time of the crash. + +This only happens to one VM at a time, independently. The other VMs appear to run fine when one VM encounters the problem. + +I which instructions to further debug this. + +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/architecture-x86/1504528 b/results/classifier/118/architecture-x86/1504528 new file mode 100644 index 000000000..86b31c8d8 --- /dev/null +++ b/results/classifier/118/architecture-x86/1504528 @@ -0,0 +1,78 @@ +x86: 0.995 +architecture: 0.848 +device: 0.847 +PID: 0.811 +network: 0.776 +user-level: 0.770 +vnc: 0.745 +ppc: 0.726 +VMM: 0.674 +graphic: 0.665 +hypervisor: 0.661 +performance: 0.634 +i386: 0.626 +TCG: 0.605 +files: 0.589 +kernel: 0.563 +register: 0.548 +semantic: 0.531 +arm: 0.524 +mistranslation: 0.517 +boot: 0.463 +debug: 0.444 +socket: 0.435 +virtual: 0.394 +KVM: 0.389 +risc-v: 0.389 +permissions: 0.379 +peripherals: 0.193 +assembly: 0.079 +-------------------- +x86: 0.957 +debug: 0.856 +user-level: 0.423 +PID: 0.177 +performance: 0.088 +TCG: 0.043 +register: 0.023 +virtual: 0.023 +hypervisor: 0.019 +files: 0.014 +semantic: 0.014 +device: 0.003 +VMM: 0.002 +architecture: 0.002 +assembly: 0.001 +network: 0.001 +ppc: 0.001 +KVM: 0.001 +kernel: 0.001 +permissions: 0.001 +boot: 0.001 +graphic: 0.001 +socket: 0.001 +peripherals: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +i386: 0.000 +vnc: 0.000 +arm: 0.000 + +qemu shows glib-warning with the new glib2 2.46 + +qemu shows the following warning with glib2 2.46.0: + +[tom@localhost ~]$ qemu-system-x86_64 + +(process:4222): GLib-WARNING **: gmem.c:482: custom memory allocation vtable not supported + +fwiw process 4222 is qemu-system-x86_64 + +Fixed by commit 98cf48f60aa4999f5b2808569a193a401a390e6a + +Author: Paolo Bonzini <email address hidden> +Date: Wed Sep 16 17:38:44 2015 +0200 + + trace: remove malloc tracing + + diff --git a/results/classifier/118/architecture-x86/1534382 b/results/classifier/118/architecture-x86/1534382 new file mode 100644 index 000000000..fb26eacae --- /dev/null +++ b/results/classifier/118/architecture-x86/1534382 @@ -0,0 +1,91 @@ +x86: 0.944 +graphic: 0.887 +architecture: 0.858 +performance: 0.726 +device: 0.705 +semantic: 0.648 +mistranslation: 0.597 +permissions: 0.564 +socket: 0.543 +network: 0.523 +hypervisor: 0.519 +register: 0.513 +kernel: 0.494 +boot: 0.482 +user-level: 0.470 +ppc: 0.433 +PID: 0.424 +files: 0.409 +vnc: 0.408 +risc-v: 0.389 +virtual: 0.369 +debug: 0.363 +peripherals: 0.348 +KVM: 0.345 +VMM: 0.339 +TCG: 0.327 +assembly: 0.323 +arm: 0.242 +i386: 0.069 +-------------------- +x86: 0.997 +virtual: 0.943 +debug: 0.864 +hypervisor: 0.725 +TCG: 0.358 +i386: 0.178 +user-level: 0.116 +KVM: 0.037 +socket: 0.015 +PID: 0.013 +files: 0.012 +performance: 0.008 +device: 0.004 +register: 0.004 +kernel: 0.004 +risc-v: 0.003 +network: 0.003 +VMM: 0.003 +architecture: 0.003 +semantic: 0.002 +graphic: 0.002 +assembly: 0.001 +ppc: 0.001 +vnc: 0.001 +peripherals: 0.001 +boot: 0.001 +permissions: 0.000 +arm: 0.000 +mistranslation: 0.000 + +loadvm makes Windows 7 x86 guest crash with some CPUs + +Running qemu with kvm enabled and -cpu set to some of the more "modern" CPUs, +and having Windows 7 x86 as the guest. + +After guest OS loads, start some app (I started "cmd"), then do "savevm". +After that, do some more activity (I closed cmd window and opened IE), +then do "loadvm" of the previously saved snapshot. + +loadvm shows briefly the state that the system was in at the snapshot time, +then guest OS crashes (blue screen). + +Originally I saw this problem on qemu 1.4.0, +then I also tried qemu 2.5.0 and found the same problem. + +The CPUs that I tried were mostly those that support NX bit (core2duo, +qemu64, kvm64, Nehalem, etc.) + +If I use the default CPU, or some other like qemu32/kvm32, +the problem does not occur. + +What is your host processor? + +it is Intel(R) Xeon(R) CPU E5-1410 0 @ 2.80GHz + + +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/architecture-x86/1585971 b/results/classifier/118/architecture-x86/1585971 new file mode 100644 index 000000000..ff0cbd565 --- /dev/null +++ b/results/classifier/118/architecture-x86/1585971 @@ -0,0 +1,89 @@ +architecture: 0.913 +graphic: 0.887 +device: 0.840 +x86: 0.835 +peripherals: 0.821 +performance: 0.804 +user-level: 0.758 +boot: 0.712 +semantic: 0.703 +debug: 0.700 +virtual: 0.699 +socket: 0.646 +network: 0.643 +mistranslation: 0.625 +vnc: 0.556 +KVM: 0.507 +ppc: 0.503 +register: 0.503 +files: 0.497 +PID: 0.475 +VMM: 0.458 +permissions: 0.407 +kernel: 0.367 +hypervisor: 0.364 +arm: 0.321 +assembly: 0.319 +i386: 0.268 +risc-v: 0.205 +TCG: 0.187 +-------------------- +x86: 0.964 +debug: 0.883 +hypervisor: 0.807 +kernel: 0.609 +KVM: 0.158 +TCG: 0.125 +boot: 0.055 +user-level: 0.043 +virtual: 0.021 +files: 0.013 +device: 0.012 +PID: 0.012 +performance: 0.010 +VMM: 0.009 +socket: 0.008 +architecture: 0.004 +graphic: 0.004 +network: 0.004 +semantic: 0.003 +assembly: 0.003 +ppc: 0.003 +risc-v: 0.003 +peripherals: 0.003 +vnc: 0.002 +register: 0.001 +permissions: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +Host system crashes on qemu with DMA remapping + +Hy, + +the host system crashes completely, when i try to pass an physical device without boot option intel_iommu=on set. In older kernel versions you didn't have to pass that option. + +I wonder if this can be easily checked by asking iommu state, avoiding a crash of the complete system. + +My data: +cpu model: Intel(R) Core(TM) i7 CPU +qemu version: 2.4.1-r2 +kernel version: 4.1.2 x86_64 +command line: +qemu-system-x86_64 -enable-kvm -drive file=/vms/prod/fw/fw.iso,if=virtio,format=raw -drive file=/vms/prod/fw/swap,if=virtio,format=raw -drive file=/vms/prod/fw/fwdata.iso,if=virtio,format=raw -m 512 -nographic -kernel /data/kernels/vmlinuz-2.6.36-gentoo-r8 -append "root=/dev/vda console=ttyS0 earlyprintk=serial" -net nic,model=virtio,macaddr=DE:AD:BE:EF:2D:AD -net tap,ifname=tapfw0,script=/etc/qemu/qemu-ifup -device pci-assign,host=03:00.0 + +There are also more detailed informations (if needed) here: +https://forums.gentoo.org/viewtopic-p-7923976.html + +Thanks, +Antonios. + +Sorry, i have to cancel this report. + +The problem seems to be somewhere else. After some reboots the same issue came up again. + +Triaging old bug tickets ... Can you still reproduce the issue with the latest version of QEMU and the kernel, or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-x86/1592336 b/results/classifier/118/architecture-x86/1592336 new file mode 100644 index 000000000..3323f1e29 --- /dev/null +++ b/results/classifier/118/architecture-x86/1592336 @@ -0,0 +1,92 @@ +x86: 0.915 +peripherals: 0.903 +graphic: 0.878 +device: 0.852 +architecture: 0.843 +user-level: 0.840 +KVM: 0.782 +performance: 0.755 +mistranslation: 0.695 +network: 0.623 +boot: 0.623 +semantic: 0.616 +kernel: 0.602 +PID: 0.579 +assembly: 0.571 +socket: 0.567 +permissions: 0.555 +files: 0.553 +virtual: 0.496 +ppc: 0.489 +register: 0.485 +i386: 0.450 +hypervisor: 0.421 +debug: 0.348 +arm: 0.338 +risc-v: 0.325 +VMM: 0.315 +vnc: 0.288 +TCG: 0.227 +-------------------- +x86: 0.980 +virtual: 0.974 +KVM: 0.884 +hypervisor: 0.733 +user-level: 0.494 +ppc: 0.348 +peripherals: 0.209 +debug: 0.037 +TCG: 0.031 +device: 0.025 +register: 0.024 +files: 0.019 +socket: 0.015 +semantic: 0.012 +PID: 0.011 +architecture: 0.007 +kernel: 0.005 +graphic: 0.005 +network: 0.005 +assembly: 0.004 +performance: 0.004 +boot: 0.003 +vnc: 0.002 +VMM: 0.002 +risc-v: 0.002 +permissions: 0.002 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +mouse is defunct when grabbed + +I run qemu as follows: +qemu-system-x86_64 -machine accel=kvm -k en-us -smp 4 -m 2371 -usb \ + -device virtio-rng-pci \ + -drive file=/home/new/suse-fact.img,format=raw,discard=unmap,if=none,id=hd + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -soundhw hda \ + -net user,tftp=/home/xslaby/tftp,bootfile=/pxelinux.0,hostfwd=tcp::2222-:22,hostfwd=tcp::3632-:3632 -net nic,model=virtio \ + -serial pty -balloon virtio -vga virtio -display gtk,gl=on + +When I run X server with icewm inside the machine, the cursor works until I grab the mous with ctrl-alt-g. Then the cursor dismissed and the mouse is defunct. + +I also tried -usbdevice mouse and -usbdevice tablet with the same result. + +I have these versions of qemu packages: +qemu-2.6.0-470.2.x86_64 +qemu-ipxe-1.0.0-470.2.noarch +qemu-ksm-2.6.0-470.2.x86_64 +qemu-kvm-2.6.0-470.2.x86_64 +qemu-ovmf-x86_64-2015+git1462940744.321151f-2.1.noarch +qemu-ppc-2.6.0-470.2.x86_64 +qemu-seabios-1.9.1-470.2.noarch +qemu-sgabios-8-470.2.noarch +qemu-tools-2.6.0-470.2.x86_64 +qemu-vgabios-1.9.1-470.2.noarch +qemu-x86-2.6.0-470.2.x86_64 + +Can you still reproduce the issue with the latest version of QEMU (currently v4.2)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-x86/1598029 b/results/classifier/118/architecture-x86/1598029 new file mode 100644 index 000000000..058b5e823 --- /dev/null +++ b/results/classifier/118/architecture-x86/1598029 @@ -0,0 +1,88 @@ +architecture: 0.947 +x86: 0.920 +kernel: 0.876 +device: 0.837 +graphic: 0.828 +assembly: 0.698 +arm: 0.691 +PID: 0.688 +ppc: 0.667 +boot: 0.659 +register: 0.641 +performance: 0.632 +files: 0.627 +semantic: 0.617 +mistranslation: 0.610 +network: 0.580 +permissions: 0.567 +vnc: 0.566 +socket: 0.564 +debug: 0.547 +peripherals: 0.440 +user-level: 0.418 +KVM: 0.413 +VMM: 0.385 +risc-v: 0.373 +hypervisor: 0.338 +TCG: 0.281 +virtual: 0.251 +i386: 0.018 +-------------------- +x86: 0.996 +kernel: 0.886 +virtual: 0.660 +boot: 0.640 +debug: 0.108 +hypervisor: 0.048 +TCG: 0.045 +user-level: 0.026 +PID: 0.023 +semantic: 0.018 +files: 0.017 +device: 0.012 +socket: 0.011 +performance: 0.010 +risc-v: 0.009 +architecture: 0.005 +register: 0.005 +network: 0.004 +vnc: 0.003 +permissions: 0.003 +graphic: 0.002 +assembly: 0.002 +peripherals: 0.001 +KVM: 0.001 +mistranslation: 0.001 +VMM: 0.001 +ppc: 0.001 +i386: 0.000 +arm: 0.000 + +failed to boot a customized kernel if emulating Broadwell/Skylake + +Hardware: X86-64, Intel(R) Core(TM) i7-6500U( Skylake) +OS: Linux Mint 18 +Host Kernel: 4.5.7 + PaX/Grsecurity +Qemu: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.2) + +[Reproduction Steps] +1, Install a Debian 8 in the guest +2, Install a customized kernel( using same config to Debian 8) +3, Reboot: +qemu-system-x86_64 -hda debian8-test.img -boot d -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Broadwell -smp 2 + +or + +qemu-system-x86_64 -hda debian8-test.img -boot d -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu host -smp 2 + +[Actual Result] +kernel panic or can't login in the system + +[Workaround] +qemu-system-x86_64 -hda debian8-test.img -boot d -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Haswell -smp 2 + +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/architecture-x86/1605123 b/results/classifier/118/architecture-x86/1605123 new file mode 100644 index 000000000..3be8e6eda --- /dev/null +++ b/results/classifier/118/architecture-x86/1605123 @@ -0,0 +1,97 @@ +x86: 0.966 +architecture: 0.952 +graphic: 0.887 +ppc: 0.877 +performance: 0.804 +semantic: 0.794 +i386: 0.779 +device: 0.717 +files: 0.654 +mistranslation: 0.618 +network: 0.597 +user-level: 0.584 +permissions: 0.553 +vnc: 0.552 +arm: 0.546 +PID: 0.531 +TCG: 0.528 +peripherals: 0.516 +risc-v: 0.488 +boot: 0.485 +socket: 0.475 +hypervisor: 0.460 +kernel: 0.458 +register: 0.457 +VMM: 0.440 +virtual: 0.428 +debug: 0.390 +KVM: 0.329 +assembly: 0.215 +-------------------- +x86: 0.979 +kernel: 0.837 +debug: 0.470 +user-level: 0.352 +virtual: 0.103 +hypervisor: 0.089 +files: 0.084 +register: 0.017 +TCG: 0.014 +i386: 0.012 +semantic: 0.005 +PID: 0.005 +assembly: 0.004 +network: 0.003 +device: 0.002 +performance: 0.002 +architecture: 0.002 +KVM: 0.001 +VMM: 0.001 +socket: 0.001 +graphic: 0.001 +boot: 0.001 +ppc: 0.001 +peripherals: 0.001 +risc-v: 0.001 +vnc: 0.000 +permissions: 0.000 +mistranslation: 0.000 +arm: 0.000 + +PEXT returns wrong values, seemingly switches arguments + +Hi, + +I fiddled with BMI2 instructions and discovered that pext instructions +emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It +seemingly switches up its arguments. I suspect that the error is around the +gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext +in target-i386/int_helper.c and it works fine. + +I ran my program on a CPU with BMI2 instruction set too, and it indeed +returns different values. + +I didn't check pdep, it could have the same problem. + +$ qemu-x86_64 --version +qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux + +I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". + +$ gcc --version +gcc (Debian 5.4.0-6) 5.4.0 20160609 + +Best regards, +Lénárd Szolnoki + + + +Paolo sent a patch here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05700.html + +Fix has been committed: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=75b208c28316095c4685 + diff --git a/results/classifier/118/architecture-x86/1606708 b/results/classifier/118/architecture-x86/1606708 new file mode 100644 index 000000000..f0afa885f --- /dev/null +++ b/results/classifier/118/architecture-x86/1606708 @@ -0,0 +1,86 @@ +architecture: 0.975 +x86: 0.941 +performance: 0.919 +graphic: 0.875 +device: 0.787 +i386: 0.737 +semantic: 0.639 +arm: 0.550 +mistranslation: 0.454 +user-level: 0.394 +ppc: 0.276 +socket: 0.274 +vnc: 0.268 +assembly: 0.262 +network: 0.254 +peripherals: 0.248 +boot: 0.242 +kernel: 0.238 +permissions: 0.233 +debug: 0.198 +register: 0.189 +PID: 0.171 +risc-v: 0.158 +virtual: 0.113 +VMM: 0.102 +files: 0.098 +hypervisor: 0.053 +TCG: 0.049 +KVM: 0.029 +-------------------- +user-level: 0.943 +x86: 0.840 +virtual: 0.317 +TCG: 0.100 +debug: 0.077 +hypervisor: 0.027 +performance: 0.020 +register: 0.014 +PID: 0.009 +files: 0.008 +device: 0.003 +VMM: 0.003 +network: 0.003 +semantic: 0.002 +kernel: 0.002 +ppc: 0.002 +risc-v: 0.002 +graphic: 0.001 +architecture: 0.001 +boot: 0.001 +peripherals: 0.001 +socket: 0.001 +arm: 0.001 +assembly: 0.001 +i386: 0.001 +permissions: 0.000 +vnc: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +QEMU crashes when switching consoles using SDL + +I've trying to use QEMU with SDL, and I noticed that it doesn't behave well, specially when switching from VGA to any console. Resuming, switching is erratic when using SDL, and its effects go from creating a new window, doing nothing, showing a window that disappears inmediately or even crash. + +Tested with: +Arch Linux with all packages updated (2016/7/26) +TWM as window manager +QEMU (both stable 2.6.0-1 and latest git commit f49ee63) +Command: qemu-system-x86_64 -display sdl + +sdl2 version 2.0.4-2 + +How to reproduce: +1. Open QEMU with the given command +2. Try to switch console (Ctrl-Alt-2 for example) + +Expected behaviour: +As in GTK, the window should now show the desired console + +Actual behaviour: +Here I have to say I can't explain it very well. Almost always it just creates a new window that shows the desired console, but it is closed inmediatley. If not, it opens a new window that keeps open, and it sometimes is responsive, but further attempts to switch consoles end causing a crash, and QEMU has to be SIGKILLed + +I think this should be fixed with the latest version of QEMU ... or can you still reproduce this issue with the latest version? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-x86/1648 b/results/classifier/118/architecture-x86/1648 new file mode 100644 index 000000000..f237c54c0 --- /dev/null +++ b/results/classifier/118/architecture-x86/1648 @@ -0,0 +1,118 @@ +x86: 0.957 +i386: 0.949 +architecture: 0.834 +permissions: 0.763 +device: 0.723 +performance: 0.709 +kernel: 0.692 +assembly: 0.603 +ppc: 0.599 +socket: 0.563 +peripherals: 0.560 +vnc: 0.505 +PID: 0.500 +network: 0.482 +user-level: 0.481 +register: 0.470 +graphic: 0.460 +files: 0.442 +boot: 0.428 +hypervisor: 0.410 +semantic: 0.379 +arm: 0.356 +VMM: 0.355 +KVM: 0.352 +risc-v: 0.333 +TCG: 0.328 +debug: 0.301 +virtual: 0.217 +mistranslation: 0.206 +-------------------- +debug: 0.948 +user-level: 0.938 +architecture: 0.193 +x86: 0.169 +register: 0.064 +kernel: 0.040 +TCG: 0.033 +files: 0.031 +PID: 0.020 +assembly: 0.019 +performance: 0.017 +semantic: 0.010 +hypervisor: 0.007 +device: 0.004 +virtual: 0.003 +peripherals: 0.002 +boot: 0.002 +network: 0.002 +KVM: 0.002 +socket: 0.001 +VMM: 0.001 +permissions: 0.001 +graphic: 0.001 +vnc: 0.001 +i386: 0.001 +mistranslation: 0.001 +risc-v: 0.000 +ppc: 0.000 +arm: 0.000 + +linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash +Description of problem: +Corrent Print Result: + +sp: cdd3b4e8 + +SUCCEEDED! + +qemu-x86_64 Print Result: + +sp: 2804170 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Segmentation fault + +Reason of Bug: + +sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*) + +For example on x86_64: + +reference to "qemu/linux-user/i386/signal.c" + +``` +# define TARGET_FPSTATE_FXSAVE_OFFSET 0 + +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + struct target_fpstate fpstate QEMU_ALIGNED(16); +}; +#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET ( \ + offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET) +``` + +offsetof(struct rt_sigframe, fpstate) align of 16 + +TARGET_FPSTATE_FXSAVE_OFFSET is 0 + +TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64 + +so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect! + +Fix the bug: + +``` +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + abi_ulong unused QEMU_ALIGNED(16); + struct target_fpstate fpstate; +}; +``` + +offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64. diff --git a/results/classifier/118/architecture-x86/1657010 b/results/classifier/118/architecture-x86/1657010 new file mode 100644 index 000000000..bc1a69e17 --- /dev/null +++ b/results/classifier/118/architecture-x86/1657010 @@ -0,0 +1,81 @@ +x86: 0.989 +architecture: 0.956 +device: 0.827 +graphic: 0.789 +TCG: 0.757 +performance: 0.697 +risc-v: 0.667 +ppc: 0.632 +register: 0.608 +network: 0.588 +permissions: 0.575 +semantic: 0.566 +arm: 0.549 +boot: 0.540 +vnc: 0.527 +socket: 0.461 +mistranslation: 0.455 +kernel: 0.451 +files: 0.429 +PID: 0.391 +hypervisor: 0.379 +i386: 0.345 +debug: 0.336 +virtual: 0.329 +assembly: 0.328 +user-level: 0.315 +VMM: 0.302 +KVM: 0.196 +peripherals: 0.147 +-------------------- +TCG: 0.876 +x86: 0.830 +ppc: 0.653 +architecture: 0.365 +virtual: 0.205 +arm: 0.194 +hypervisor: 0.070 +register: 0.041 +performance: 0.023 +KVM: 0.019 +files: 0.010 +user-level: 0.010 +kernel: 0.009 +PID: 0.009 +i386: 0.007 +network: 0.006 +device: 0.005 +semantic: 0.005 +socket: 0.004 +debug: 0.003 +boot: 0.003 +risc-v: 0.002 +VMM: 0.002 +peripherals: 0.001 +permissions: 0.001 +assembly: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +RFE: Please implement -cpu best or a CPU fallback option + +QEMU should implement a -cpu best option or some other way to make this work: + +qemu -M pc,accel=kvm:tcg -cpu best + +qemu -M pc,accel=kvm:tcg -cpu host:qemu64 + +See also: + +https://bugzilla.redhat.com/show_bug.cgi?id=1277744#c6 + +Instead of having a new CPU model called "best", we can simply make "-cpu host" available on TCG. I have submitted a patch for this yesterday: + +https://<email address hidden>/msg422959.html + +I think we've ended up with '-cpu max', present since QEMU 2.9 for x86 and perhaps for some other architectures, but not Arm yet. + + +As far as I can see, we have "-cpu max" now for x86, arm, ppc and s390x ... is that enough, so that we can close this bug now? + diff --git a/results/classifier/118/architecture-x86/1659901 b/results/classifier/118/architecture-x86/1659901 new file mode 100644 index 000000000..a799e40a8 --- /dev/null +++ b/results/classifier/118/architecture-x86/1659901 @@ -0,0 +1,87 @@ +x86: 0.878 +architecture: 0.855 +debug: 0.838 +user-level: 0.822 +device: 0.770 +boot: 0.760 +graphic: 0.737 +semantic: 0.731 +arm: 0.673 +performance: 0.649 +ppc: 0.601 +register: 0.578 +socket: 0.491 +permissions: 0.446 +kernel: 0.390 +VMM: 0.380 +PID: 0.380 +network: 0.348 +hypervisor: 0.339 +risc-v: 0.307 +files: 0.296 +vnc: 0.282 +peripherals: 0.264 +virtual: 0.227 +mistranslation: 0.219 +assembly: 0.146 +TCG: 0.116 +i386: 0.102 +KVM: 0.029 +-------------------- +debug: 0.969 +arm: 0.942 +user-level: 0.882 +virtual: 0.777 +network: 0.673 +TCG: 0.031 +files: 0.024 +hypervisor: 0.014 +x86: 0.012 +performance: 0.010 +register: 0.009 +socket: 0.008 +PID: 0.006 +risc-v: 0.005 +architecture: 0.005 +boot: 0.003 +device: 0.003 +kernel: 0.002 +vnc: 0.002 +i386: 0.002 +semantic: 0.002 +ppc: 0.002 +VMM: 0.001 +assembly: 0.001 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +Regression: SIGSEGV running Java + +I have a build script that bootstraps a Debian armhf image. Part of the process involves running a Java program while inside a chroot. I am using Debian's qemu-user-static package to run the armhf Java binary on an amd64 system. + +qemu-user-static version 1:2.7+dfsg-3~bpo8+2 works fine. Version 1:2.8+dfsg-1~bpo8+1 always causes Java to crash with a SIGSEGV. The location of the crash appears to be random and hasn't been the same twice. + +I am using the Azul Systems Zulu Embedded Java runtime, rather than the regular OpenJDK runtime, because the Zulu runtime has an arm32 JIT whereas OpenJDK is interpreter-only on arm32. + +I can reproduce the problem easily by mounting the image created by my build script and executing "java -XshowSettings -version" in a chroot. I can give you the image if that would help debug the problem. + +Additional investigation reveals the problem has something to do with the Azul ARM32 JIT. If I run Java with -Xint to force interpreter-only mode, this problem doesn't occur. + +Similar issue reported in two other places on the net: + +https://github.com/multiarch/qemu-user-static/issues/18 "qemu-arm-static 2.8 and Java+Maven setup not working" + +https://bugs.linaro.org/show_bug.cgi?id=3259#c4 Bug 3259 - Javac fails within qemu-aarch64-static chroot on x86 + +fyi, similar seen for Raspbian9: + +https://bugs.launchpad.net/raspbian/+bug/1732556 + +Hi -- I believe we fixed the Java crashes as part of work done for the 2.12 release (and perhaps 3.0, I forget). Does this still reproduce with the most recent release of QEMU (eg the 4.0 release candidate) ? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-x86/1694 b/results/classifier/118/architecture-x86/1694 new file mode 100644 index 000000000..ba510a183 --- /dev/null +++ b/results/classifier/118/architecture-x86/1694 @@ -0,0 +1,61 @@ +architecture: 0.967 +mistranslation: 0.939 +x86: 0.827 +device: 0.647 +arm: 0.514 +graphic: 0.499 +semantic: 0.300 +performance: 0.298 +register: 0.283 +files: 0.274 +debug: 0.272 +vnc: 0.270 +virtual: 0.214 +assembly: 0.197 +PID: 0.178 +ppc: 0.175 +permissions: 0.170 +boot: 0.145 +peripherals: 0.098 +hypervisor: 0.094 +socket: 0.087 +VMM: 0.087 +risc-v: 0.084 +network: 0.075 +TCG: 0.065 +user-level: 0.062 +kernel: 0.045 +i386: 0.024 +KVM: 0.011 +-------------------- +x86: 0.982 +PID: 0.417 +architecture: 0.249 +files: 0.205 +user-level: 0.176 +debug: 0.122 +TCG: 0.046 +KVM: 0.038 +virtual: 0.038 +register: 0.028 +semantic: 0.017 +performance: 0.016 +kernel: 0.015 +VMM: 0.013 +boot: 0.010 +device: 0.010 +assembly: 0.008 +socket: 0.005 +risc-v: 0.005 +hypervisor: 0.004 +graphic: 0.003 +ppc: 0.003 +i386: 0.002 +permissions: 0.002 +network: 0.001 +peripherals: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +cpu-x86-uarch-abi.py is missing "xsave" cpuid for x86-64-v3 && x86-64-v4 diff --git a/results/classifier/118/architecture-x86/1719984 b/results/classifier/118/architecture-x86/1719984 new file mode 100644 index 000000000..cc64844c8 --- /dev/null +++ b/results/classifier/118/architecture-x86/1719984 @@ -0,0 +1,74 @@ +x86: 0.978 +graphic: 0.887 +architecture: 0.875 +mistranslation: 0.851 +device: 0.786 +kernel: 0.785 +network: 0.762 +semantic: 0.650 +boot: 0.624 +performance: 0.608 +socket: 0.597 +vnc: 0.595 +register: 0.579 +risc-v: 0.540 +ppc: 0.513 +virtual: 0.513 +permissions: 0.511 +PID: 0.511 +TCG: 0.482 +peripherals: 0.449 +files: 0.420 +VMM: 0.406 +hypervisor: 0.363 +KVM: 0.312 +i386: 0.226 +user-level: 0.211 +arm: 0.211 +debug: 0.183 +assembly: 0.157 +-------------------- +x86: 0.922 +virtual: 0.917 +debug: 0.618 +kernel: 0.613 +assembly: 0.299 +register: 0.086 +semantic: 0.035 +files: 0.020 +PID: 0.020 +performance: 0.019 +hypervisor: 0.017 +VMM: 0.014 +architecture: 0.009 +user-level: 0.008 +TCG: 0.005 +boot: 0.005 +KVM: 0.003 +socket: 0.002 +device: 0.002 +network: 0.002 +graphic: 0.002 +mistranslation: 0.002 +risc-v: 0.001 +permissions: 0.001 +peripherals: 0.001 +ppc: 0.001 +vnc: 0.000 +i386: 0.000 +arm: 0.000 + +wrgsbase misemulated in x86_64-softmmu + +qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4 +command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true ' + +On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1. In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference. + +For further data, the faulting instruction is +f3 48 0f ae df wrgsbase %rdi + +Fix is in staging: https://github.com/ehabkost/qemu/commit/cdcc80d41360e278b45c91de29a29d797264e85d + +Fix is in master: https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550 + diff --git a/results/classifier/118/architecture-x86/1734792 b/results/classifier/118/architecture-x86/1734792 new file mode 100644 index 000000000..eae2e5664 --- /dev/null +++ b/results/classifier/118/architecture-x86/1734792 @@ -0,0 +1,80 @@ +x86: 0.971 +architecture: 0.889 +device: 0.885 +peripherals: 0.809 +graphic: 0.751 +performance: 0.725 +arm: 0.700 +mistranslation: 0.672 +user-level: 0.660 +semantic: 0.634 +network: 0.555 +boot: 0.432 +permissions: 0.429 +debug: 0.392 +socket: 0.376 +register: 0.375 +PID: 0.357 +vnc: 0.321 +files: 0.310 +kernel: 0.279 +risc-v: 0.272 +hypervisor: 0.223 +ppc: 0.214 +VMM: 0.204 +virtual: 0.138 +TCG: 0.110 +assembly: 0.055 +KVM: 0.049 +i386: 0.029 +-------------------- +x86: 0.924 +user-level: 0.796 +virtual: 0.739 +ppc: 0.146 +files: 0.070 +TCG: 0.054 +register: 0.037 +hypervisor: 0.019 +debug: 0.013 +PID: 0.010 +semantic: 0.009 +kernel: 0.008 +device: 0.008 +arm: 0.007 +architecture: 0.005 +assembly: 0.005 +socket: 0.003 +boot: 0.003 +performance: 0.002 +peripherals: 0.002 +network: 0.002 +permissions: 0.002 +VMM: 0.001 +i386: 0.001 +KVM: 0.001 +risc-v: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +linux-user mode does not support memfd_create syscall + +qemu-x86_66 GIT HEAD fails on a userspace application that requires memfd_create with: + +"qemu: Unsupported syscall: 319". + +memfd_create support needs to be implemented in QEMU. + +Not only qemu-x86_64, but also: + +qemu-aarch64 => qemu: Unsupported syscall: 279 +qemu-arm => qemu: Unsupported syscall: 385 +qemu-mips => qemu: Unsupported syscall: 4354 +qemu-mips64 => qemu: Unsupported syscall: 5314 +qemu-powerpc => qemu: Unsupported syscall: 360 +qemu-powerpc64 => qemu: Unsupported syscall: 360 + +9bdfa4d23f43 linux-user: add memfd_create + + diff --git a/results/classifier/118/architecture-x86/1761027 b/results/classifier/118/architecture-x86/1761027 new file mode 100644 index 000000000..d1ebc43f6 --- /dev/null +++ b/results/classifier/118/architecture-x86/1761027 @@ -0,0 +1,96 @@ +x86: 0.855 +architecture: 0.836 +semantic: 0.835 +kernel: 0.761 +device: 0.738 +ppc: 0.701 +user-level: 0.692 +files: 0.677 +performance: 0.650 +PID: 0.647 +socket: 0.617 +graphic: 0.610 +permissions: 0.595 +arm: 0.593 +mistranslation: 0.591 +peripherals: 0.578 +vnc: 0.572 +TCG: 0.533 +register: 0.533 +boot: 0.533 +network: 0.529 +risc-v: 0.467 +VMM: 0.399 +hypervisor: 0.395 +debug: 0.383 +KVM: 0.283 +assembly: 0.254 +virtual: 0.245 +i386: 0.087 +-------------------- +user-level: 0.857 +debug: 0.205 +x86: 0.159 +hypervisor: 0.149 +virtual: 0.076 +files: 0.041 +TCG: 0.027 +register: 0.025 +PID: 0.018 +device: 0.014 +semantic: 0.011 +socket: 0.010 +kernel: 0.009 +network: 0.008 +boot: 0.007 +assembly: 0.006 +risc-v: 0.005 +arm: 0.004 +architecture: 0.004 +performance: 0.004 +VMM: 0.003 +vnc: 0.002 +graphic: 0.002 +peripherals: 0.001 +i386: 0.001 +mistranslation: 0.001 +permissions: 0.001 +KVM: 0.001 +ppc: 0.000 + +Unexpected error: "AioContext polling is not implemented on Windows" + +When run it this error happens: +Unexpected error in aio_context_set_poll_params() at /home/stefan/src/qemu/repo.or.cz/qemu/ar7/util/aio-win32.c:413: +C:\Program Files\qemu\qemu-system-x86_64.exe: AioContext polling is not implemented on Windows + +This application has requested the Runtime to terminate it in an unusual way. +Please contact the application's support team for more information. + + + +System: +Windows 10 x64 + +Which version of QEMU are you using? And which parameters are you using when you start it? + +I have that message too with this version: + +c:\Tools\QEMU>qemu-system-aarch64.exe -version +QEMU emulator version 2.11.90 (v2.12.0-rc0-11704-g30195e9d53-dirty) + +My launch params are: +C:\TOOLS\QEMU\qemu-system-aarch64.exe -M raspi3 -kernel D:\QEMU-img\2017-12-04-pcudev01l.img + +My system is Windows 7 64bit +The qemu package downloaded is the 64bit version. + + +Fixed in qemu.git/master and due to be released in QEMU 2.12: + +commit 90c558beca0c0ef26db1ed77d1eb8f24a5ea02a1 +Author: Peter Xu <email address hidden> +Date: Thu Mar 22 16:56:30 2018 +0800 + + iothread: fix breakage on windows + diff --git a/results/classifier/118/architecture-x86/1785308 b/results/classifier/118/architecture-x86/1785308 new file mode 100644 index 000000000..6448b05ee --- /dev/null +++ b/results/classifier/118/architecture-x86/1785308 @@ -0,0 +1,90 @@ +x86: 0.918 +architecture: 0.914 +graphic: 0.874 +KVM: 0.829 +user-level: 0.809 +performance: 0.803 +virtual: 0.774 +hypervisor: 0.739 +semantic: 0.723 +device: 0.719 +register: 0.704 +socket: 0.676 +debug: 0.672 +ppc: 0.624 +kernel: 0.603 +files: 0.580 +PID: 0.579 +TCG: 0.560 +permissions: 0.560 +network: 0.548 +vnc: 0.527 +risc-v: 0.518 +boot: 0.508 +mistranslation: 0.482 +peripherals: 0.436 +assembly: 0.418 +VMM: 0.414 +i386: 0.378 +arm: 0.252 +-------------------- +x86: 0.999 +debug: 0.968 +virtual: 0.815 +i386: 0.540 +TCG: 0.052 +register: 0.037 +PID: 0.031 +performance: 0.022 +socket: 0.022 +files: 0.020 +architecture: 0.018 +user-level: 0.015 +KVM: 0.014 +kernel: 0.014 +boot: 0.013 +device: 0.012 +risc-v: 0.010 +vnc: 0.010 +hypervisor: 0.009 +semantic: 0.008 +network: 0.007 +assembly: 0.005 +VMM: 0.004 +graphic: 0.002 +peripherals: 0.002 +permissions: 0.002 +ppc: 0.002 +mistranslation: 0.001 +arm: 0.000 + +0x8 exception encountered but not handled + +Present in all QEMU versions. + +OS is triple page faulting and crashing rather than handling the expected double page fault properly. The same OS works in Bochs so I know its not the problem. + +Hi Ra, + We'll need a bit more detail to be able to help here. +The fact something works in Bochs but doesn't work in qemu doesn't necessarily mean it's a qemu bug - for example the OS might be hitting something undefined or a timing issue; so we'd need some information on how the double page fault happened. +Does it work with KVM enabled? With tcg? What version of qemu are you using? + +Hi David, + The OS is hitting something undefined. It's built on exploiting the x86 architecture to run computations of the MMU rather than the CPU: https://github.com/jbangert/trapcc +I've tried it on the 3 most recent versions of QEMU for Windows. I'll give it a go with KVM and tcg and get back to you although I'm not hopeful. + +OK, that's just a cruel test :-) +It'll be interesting to see the difference between TCG and KVM, but with such a weird test case as that you'll probably need to narrow the problem down more. + + +What would be useful information to narrow down the problem? Any specific kind of logs from running it in TCG and KVM? + +I think I'd start by seeing if it fails in both or if they're different. +If they're different then you'd follow the series of exceptions that they each get +and see where they diverge. + +More generally, I think that if you care about getting this test case to work under QEMU emulation you're going to have to be prepared to dig into QEMU's internals to debug where we diverge from what the real CPU does. Our x86 emulation is not very actively maintained and this isn't a "real world" use case that many users are going to have problems with, so my guess is it is unlikely to be fixed unless somebody with enough interest in it to take a day or a week to debug what's going on does that work. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-x86/1790260 b/results/classifier/118/architecture-x86/1790260 new file mode 100644 index 000000000..4061b8df0 --- /dev/null +++ b/results/classifier/118/architecture-x86/1790260 @@ -0,0 +1,87 @@ +x86: 0.893 +graphic: 0.849 +architecture: 0.828 +user-level: 0.717 +performance: 0.703 +semantic: 0.691 +device: 0.654 +mistranslation: 0.643 +ppc: 0.628 +register: 0.590 +network: 0.588 +permissions: 0.583 +debug: 0.565 +risc-v: 0.552 +files: 0.543 +vnc: 0.535 +PID: 0.533 +kernel: 0.527 +VMM: 0.517 +peripherals: 0.502 +socket: 0.449 +hypervisor: 0.430 +boot: 0.425 +TCG: 0.403 +virtual: 0.385 +i386: 0.367 +KVM: 0.320 +assembly: 0.316 +arm: 0.310 +-------------------- +x86: 0.966 +user-level: 0.932 +i386: 0.694 +hypervisor: 0.486 +virtual: 0.420 +TCG: 0.089 +debug: 0.058 +kernel: 0.055 +files: 0.050 +PID: 0.009 +risc-v: 0.008 +architecture: 0.008 +semantic: 0.007 +performance: 0.005 +network: 0.004 +device: 0.003 +boot: 0.003 +ppc: 0.003 +register: 0.003 +socket: 0.002 +vnc: 0.001 +assembly: 0.001 +permissions: 0.001 +peripherals: 0.001 +arm: 0.001 +graphic: 0.001 +VMM: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +binfmt support not working for x86 host and x86_64 guest + +this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere else. the version i checked is the current github mirror https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh + +i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run some applications that are only available as x86_64 packages. i use multiarch and qemu and it works for simple applications like cacafire. however i want to run the application natively from the shell without having to use qemu-x86_64 <path>. i also installed the binfmt-support package. when i run update-binfmts --display then an extry for x86_64 is missing and transparent execution is not working. + +the problem seems to be in the qemu-binfmt-conf.sh script. it disables the creation of entries for cpus of the same family. this is not a problem if you are using a 64bit cpu because 32bit binaries run on it natively but it doesnt work in the opposite way. hacking line 310 to + + if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ; then + +and running it with the --systemd ALL parameter causes a x86_64 config file to be created. it still doesnt work but that might have different causes. + +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/architecture-x86/1852115 b/results/classifier/118/architecture-x86/1852115 new file mode 100644 index 000000000..f476efb38 --- /dev/null +++ b/results/classifier/118/architecture-x86/1852115 @@ -0,0 +1,113 @@ +x86: 0.892 +architecture: 0.878 +user-level: 0.865 +graphic: 0.823 +performance: 0.821 +socket: 0.786 +kernel: 0.775 +arm: 0.773 +hypervisor: 0.767 +device: 0.766 +ppc: 0.760 +PID: 0.735 +files: 0.723 +mistranslation: 0.704 +peripherals: 0.691 +debug: 0.686 +boot: 0.669 +network: 0.658 +risc-v: 0.651 +TCG: 0.616 +i386: 0.610 +register: 0.587 +semantic: 0.582 +permissions: 0.580 +VMM: 0.571 +vnc: 0.569 +KVM: 0.501 +assembly: 0.385 +virtual: 0.368 +-------------------- +x86: 0.953 +files: 0.059 +debug: 0.036 +TCG: 0.031 +PID: 0.012 +hypervisor: 0.012 +semantic: 0.011 +virtual: 0.010 +register: 0.010 +user-level: 0.007 +kernel: 0.006 +VMM: 0.004 +boot: 0.003 +device: 0.003 +network: 0.003 +architecture: 0.003 +KVM: 0.002 +performance: 0.002 +assembly: 0.002 +permissions: 0.002 +vnc: 0.001 +socket: 0.001 +graphic: 0.001 +mistranslation: 0.001 +peripherals: 0.001 +i386: 0.001 +risc-v: 0.001 +arm: 0.001 +ppc: 0.000 + +qemu --static user build fails with fedora rawhide glibc-2.30.9000 + +Building qemu latest git 654efcb511d on fedora rawhide fails with this configure line: + +./configure \ + --static \ + --disable-system \ + --enable-linux-user \ + --disable-werror \ + --disable-tools \ + --disable-capstone + +make fails with: + +/usr/bin/ld: linux-user/syscall.o: in function `do_syscall1': +/root/qemu.git/linux-user/syscall.c:7769: undefined reference to `stime' +collect2: error: ld returned 1 exit status + +Seems related to this glibc change: https://sourceware.org/git/?p=glibc.git;a=commit;h=12cbde1dae6fa4a9a792b64564c7e0debf7544cc + +... + ++* The obsolete function stime is no longer available to newly linked ++ binaries and it has been removed from <time.h> header. This function ++ has been deprecated in favor of clock_settime. ++ + +# rpm -q glibc +glibc-2.30.9000-17.fc32.x86_64 + + +FWIW there's some other messages but I don't think they are fatal: + +/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0xe0): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0x11e): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking + + +Also, --disable-capstone is required to avoid this error, but it is pre-existing, not sure if it's a bug, if so I can file a separate one: + + LINK aarch64-linux-user/qemu-aarch64 +/usr/bin/ld: cannot find -lcapstone +collect2: error: ld returned 1 exit status + +We use stime() to implement the target stime syscall. We should probably switch to using clock_settime(CLOCK_REALTIME, ...) instead, as that's what glibc uses internally now to implement its stime(): + +https://sourceware.org/git/?p=glibc.git;a=blob;f=time/stime.c;h=6ea3b6dcc1a393b57b69ca24fbfe8023d9095837;hb=12cbde1dae6fa4a9a792b64564c7e0debf7544cc + + +Fixed by 0f1f2d4596ae ("linux-user: remove host stime() syscall") + + diff --git a/results/classifier/118/architecture-x86/1884302 b/results/classifier/118/architecture-x86/1884302 new file mode 100644 index 000000000..22ea4b4d0 --- /dev/null +++ b/results/classifier/118/architecture-x86/1884302 @@ -0,0 +1,94 @@ +x86: 0.953 +architecture: 0.881 +device: 0.792 +graphic: 0.782 +kernel: 0.778 +i386: 0.764 +files: 0.747 +socket: 0.708 +ppc: 0.695 +performance: 0.681 +user-level: 0.666 +hypervisor: 0.657 +network: 0.655 +register: 0.619 +virtual: 0.616 +semantic: 0.578 +KVM: 0.574 +peripherals: 0.569 +PID: 0.568 +vnc: 0.547 +permissions: 0.544 +debug: 0.482 +mistranslation: 0.465 +arm: 0.456 +assembly: 0.450 +boot: 0.445 +risc-v: 0.428 +VMM: 0.375 +TCG: 0.280 +-------------------- +user-level: 0.963 +x86: 0.923 +hypervisor: 0.907 +virtual: 0.905 +TCG: 0.042 +debug: 0.028 +files: 0.013 +network: 0.007 +PID: 0.006 +kernel: 0.006 +device: 0.005 +socket: 0.005 +architecture: 0.003 +semantic: 0.003 +peripherals: 0.003 +KVM: 0.003 +graphic: 0.003 +performance: 0.002 +risc-v: 0.002 +VMM: 0.002 +register: 0.002 +permissions: 0.002 +vnc: 0.001 +boot: 0.001 +assembly: 0.001 +ppc: 0.001 +arm: 0.001 +i386: 0.001 +mistranslation: 0.000 + +disable automatic mouse grabbing + +I'm using QEMU 5.0.0 on a Gentoo Linux host system. Guest is an Arch Linux system. + +I'd like to disable automatic mouse grabbing when the QEMU window is focused. +I would prefer for QEMU to grab the mouse only after a click. + +I use the i3 window manager on my host system. +Suppose I'm in workspace 1, while the QEMU window is in workspace 2. +In order to switch to workspace 2, I need to press the "Win+2" key combination ("Win" is the Windows key). +The problem is that the character "2" (from "Win+2") will get transferred to the guest system. +For example, if I have a text editor opened under the guest system, the character "2" will be pasted inside the document I'm working on, which is pretty annoying. + +I would like instead to press the "Win+2" key combination and then explicitely click on the QEMU window with the mouse before grabbing it. + +Command line: + +qemu-system-x86_64 -drive file=/home/fturco/qemu/arch.img,media=disk,index=0,if=virtio,format=raw,cache=none -cpu host -m 2G -k it -enable-kvm -net nic,model=virtio -net user -vga virtio -display sdl -usb -rtc base=utc -soundhw ac97 -monitor stdio -no-quit + +Possibly similar bug: https://bugs.launchpad.net/qemu/+bug/906864 + +FYI: The gtk ui has support for that. Try "-display gtk,grab-on-hover=off". You can also toggle it in the "view" menu. + +Thanks for the info, but I prefer to continue using the SDL interface, if possible. +Is there a plan to add the grab-on-hover=off option to the SDL interface? + + +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/75 + + diff --git a/results/classifier/118/architecture-x86/1910540 b/results/classifier/118/architecture-x86/1910540 new file mode 100644 index 000000000..6c66bb595 --- /dev/null +++ b/results/classifier/118/architecture-x86/1910540 @@ -0,0 +1,70 @@ +x86: 0.959 +architecture: 0.956 +mistranslation: 0.832 +graphic: 0.808 +device: 0.784 +network: 0.782 +semantic: 0.697 +arm: 0.678 +TCG: 0.661 +files: 0.593 +socket: 0.544 +vnc: 0.532 +performance: 0.529 +kernel: 0.499 +VMM: 0.460 +ppc: 0.414 +user-level: 0.376 +peripherals: 0.361 +register: 0.345 +risc-v: 0.318 +PID: 0.311 +boot: 0.308 +debug: 0.303 +hypervisor: 0.224 +permissions: 0.195 +KVM: 0.189 +virtual: 0.134 +assembly: 0.120 +i386: 0.048 +-------------------- +debug: 0.970 +user-level: 0.880 +hypervisor: 0.867 +files: 0.436 +performance: 0.251 +PID: 0.197 +TCG: 0.167 +arm: 0.132 +network: 0.053 +virtual: 0.051 +kernel: 0.036 +x86: 0.028 +semantic: 0.023 +KVM: 0.020 +device: 0.015 +boot: 0.011 +architecture: 0.007 +socket: 0.005 +VMM: 0.004 +peripherals: 0.003 +ppc: 0.003 +assembly: 0.002 +register: 0.002 +risc-v: 0.002 +permissions: 0.002 +vnc: 0.001 +graphic: 0.001 +i386: 0.001 +mistranslation: 0.000 + +where the trace file "trace-*" + +I compile qemu-system-aarch64 with --enable-trace-backends=simple option, then start qemu with -trace nvme* , qemu start successful but I cann't find the trace file "trace-*" at qemu started directory. + +I tested qemu.git/master on Linux x86_64 to confirm that the simple trace backend works. trace-$pid files are written to the current working directory. + +If QEMU prints a warning that the trace event name does not exist, try escaping the asterisk on your command-line: -trace nvme\* + +You can find the trace-event files in the source tree, if you were talking about those. Anyway, this does not really sound like a bug, so I'm closing this ticket now. If you need general help, please use the qemu-discuss mailing list or the #qemu channel on OFTC IRC instead. + diff --git a/results/classifier/118/architecture-x86/1912857 b/results/classifier/118/architecture-x86/1912857 new file mode 100644 index 000000000..61c46e41c --- /dev/null +++ b/results/classifier/118/architecture-x86/1912857 @@ -0,0 +1,104 @@ +x86: 0.900 +architecture: 0.858 +virtual: 0.825 +user-level: 0.792 +hypervisor: 0.777 +device: 0.776 +network: 0.769 +graphic: 0.761 +socket: 0.736 +permissions: 0.731 +mistranslation: 0.728 +PID: 0.715 +performance: 0.704 +ppc: 0.700 +kernel: 0.686 +register: 0.674 +peripherals: 0.672 +files: 0.662 +KVM: 0.658 +semantic: 0.639 +arm: 0.636 +VMM: 0.549 +assembly: 0.533 +TCG: 0.530 +i386: 0.529 +debug: 0.503 +vnc: 0.487 +risc-v: 0.444 +boot: 0.439 +-------------------- +x86: 0.919 +virtual: 0.893 +user-level: 0.072 +hypervisor: 0.065 +debug: 0.051 +network: 0.036 +semantic: 0.013 +TCG: 0.013 +files: 0.013 +socket: 0.010 +PID: 0.010 +device: 0.009 +performance: 0.006 +register: 0.005 +boot: 0.005 +permissions: 0.005 +peripherals: 0.005 +architecture: 0.003 +assembly: 0.003 +risc-v: 0.003 +kernel: 0.003 +VMM: 0.003 +vnc: 0.003 +graphic: 0.003 +ppc: 0.002 +mistranslation: 0.001 +KVM: 0.001 +arm: 0.001 +i386: 0.000 + +virtio-serial blocks hostfwd ssh on windows 10 host + +qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=n1 --> WORKS - meaning I can ssh into the vm via port 2222 + +qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm + +Not only does the port 2222 work, but I am not able to perform any serial transfer on port 55298 as well. + +Host: Windows 10 +Guest: archlinux +QEMU version 5.2 + +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/architecture-x86/2082 b/results/classifier/118/architecture-x86/2082 new file mode 100644 index 000000000..a87895db7 --- /dev/null +++ b/results/classifier/118/architecture-x86/2082 @@ -0,0 +1,104 @@ +architecture: 0.934 +x86: 0.926 +performance: 0.863 +graphic: 0.834 +semantic: 0.831 +user-level: 0.715 +ppc: 0.697 +socket: 0.691 +device: 0.681 +permissions: 0.655 +PID: 0.634 +hypervisor: 0.633 +network: 0.603 +peripherals: 0.563 +files: 0.541 +VMM: 0.495 +virtual: 0.494 +kernel: 0.486 +boot: 0.467 +arm: 0.449 +register: 0.436 +debug: 0.433 +vnc: 0.399 +TCG: 0.383 +risc-v: 0.382 +mistranslation: 0.344 +assembly: 0.315 +i386: 0.289 +KVM: 0.159 +-------------------- +x86: 0.942 +virtual: 0.826 +hypervisor: 0.576 +user-level: 0.222 +files: 0.114 +register: 0.097 +TCG: 0.061 +KVM: 0.057 +debug: 0.050 +PID: 0.038 +architecture: 0.031 +kernel: 0.020 +device: 0.020 +VMM: 0.016 +socket: 0.013 +boot: 0.010 +semantic: 0.009 +vnc: 0.003 +performance: 0.003 +network: 0.002 +assembly: 0.002 +ppc: 0.002 +risc-v: 0.001 +graphic: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +"Unable to find a guest_base to satisfy all guest address mapping requirements" running certain x86_64 binaries on aarch64 host +Description of problem: +Copying from: + + https://bugzilla.redhat.com/show_bug.cgi?id=2256916 + +With ``qemu-x86_64-static`` from ``qemu-8.1.3-1.fc39``, I can no longer run on the m1 the ``x86_64`` binary created by https://github.com/containers/PodmanHello + +If I try with ``qemu-x86_64-static`` from ``qemu-7.2.7-1.fc38`` then this works. + +If I build the binary manually on a fc39 x86 system with ``gcc -O2 -static -o podman_hello_world podman_hello_world.c``, then I can also run it successfully with ``qemu-8.1.3-1.fc39``. +It's only the static binary built inside the alpine container which cannot be run on the M1. + + +Misc tests I ran: + +``` +$ ./qemu-x86_64-static-8.1.3 podman_hello_world.alpine +qemu-x86_64-static-8.1.3: /var/roothome/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements + 0000000000000000-0000000000000fff + 0000000000400000-00000000004047ef + +$ ./qemu-x86_64-static-7.2.7 podman_hello_world.alpine +!... Hello Podman World ...! +[...] + +$ ./qemu-x86_64-static-8.1.3 podman_hello_world.fc39 +!... Hello Podman World ...! +[...] +``` + +The issue is still present with ``qemu-8.2.0-0.3.rc2.fc40`` + +I also could not reproduce on ``x86_64`` machines. I just tried it on fc39 installed on non-Apple ``aarch64`` hardware, and I'm seeing the same issue: + +``` +# rpm -qf /usr/bin/qemu-x86_64-static +qemu-user-static-x86-8.1.3-1.fc39.aarch64 + +# qemu-x86_64-static ./podman_hello_world.alpine +qemu-x86_64-static: /root/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements + 0000000000000000-0000000000000fff + 0000000000400000-00000000004047ef +``` diff --git a/results/classifier/118/architecture-x86/215 b/results/classifier/118/architecture-x86/215 new file mode 100644 index 000000000..fab27f426 --- /dev/null +++ b/results/classifier/118/architecture-x86/215 @@ -0,0 +1,61 @@ +x86: 0.998 +architecture: 0.863 +device: 0.740 +mistranslation: 0.662 +kernel: 0.643 +arm: 0.587 +risc-v: 0.568 +debug: 0.550 +semantic: 0.499 +performance: 0.496 +graphic: 0.451 +ppc: 0.433 +VMM: 0.386 +i386: 0.316 +boot: 0.304 +vnc: 0.274 +PID: 0.174 +TCG: 0.162 +peripherals: 0.160 +assembly: 0.145 +socket: 0.129 +hypervisor: 0.089 +network: 0.088 +user-level: 0.087 +register: 0.058 +files: 0.053 +KVM: 0.030 +permissions: 0.020 +virtual: 0.007 +-------------------- +x86: 1.000 +i386: 0.977 +debug: 0.892 +assembly: 0.495 +performance: 0.168 +kernel: 0.058 +user-level: 0.022 +architecture: 0.021 +VMM: 0.019 +TCG: 0.010 +virtual: 0.008 +KVM: 0.007 +semantic: 0.007 +PID: 0.006 +files: 0.006 +device: 0.005 +register: 0.004 +boot: 0.004 +risc-v: 0.003 +graphic: 0.003 +peripherals: 0.002 +ppc: 0.001 +hypervisor: 0.001 +mistranslation: 0.001 +vnc: 0.001 +arm: 0.000 +socket: 0.000 +permissions: 0.000 +network: 0.000 + +x86 Floating point exceptions - incorrect support? diff --git a/results/classifier/118/architecture-x86/2175 b/results/classifier/118/architecture-x86/2175 new file mode 100644 index 000000000..a2f21118d --- /dev/null +++ b/results/classifier/118/architecture-x86/2175 @@ -0,0 +1,98 @@ +architecture: 0.835 +x86: 0.829 +device: 0.776 +graphic: 0.745 +files: 0.722 +register: 0.719 +kernel: 0.702 +assembly: 0.701 +performance: 0.701 +network: 0.686 +arm: 0.668 +PID: 0.667 +ppc: 0.660 +i386: 0.659 +vnc: 0.644 +risc-v: 0.639 +socket: 0.611 +TCG: 0.604 +mistranslation: 0.593 +hypervisor: 0.582 +user-level: 0.569 +KVM: 0.567 +permissions: 0.553 +semantic: 0.514 +boot: 0.511 +peripherals: 0.496 +debug: 0.492 +VMM: 0.489 +virtual: 0.395 +-------------------- +x86: 0.969 +assembly: 0.761 +i386: 0.286 +debug: 0.083 +user-level: 0.055 +register: 0.050 +TCG: 0.046 +files: 0.038 +semantic: 0.034 +PID: 0.024 +virtual: 0.012 +device: 0.012 +kernel: 0.010 +performance: 0.008 +hypervisor: 0.007 +peripherals: 0.006 +architecture: 0.005 +risc-v: 0.004 +VMM: 0.004 +KVM: 0.003 +boot: 0.003 +network: 0.003 +permissions: 0.002 +graphic: 0.001 +socket: 0.001 +vnc: 0.001 +mistranslation: 0.001 +ppc: 0.001 +arm: 0.000 + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/118/architecture-x86/2266 b/results/classifier/118/architecture-x86/2266 new file mode 100644 index 000000000..4507833a4 --- /dev/null +++ b/results/classifier/118/architecture-x86/2266 @@ -0,0 +1,129 @@ +x86: 0.935 +debug: 0.887 +architecture: 0.843 +files: 0.829 +ppc: 0.801 +PID: 0.792 +permissions: 0.779 +device: 0.758 +user-level: 0.722 +i386: 0.717 +hypervisor: 0.703 +graphic: 0.694 +kernel: 0.682 +semantic: 0.655 +arm: 0.634 +performance: 0.632 +network: 0.612 +socket: 0.605 +peripherals: 0.576 +KVM: 0.556 +TCG: 0.549 +VMM: 0.538 +risc-v: 0.520 +vnc: 0.519 +assembly: 0.481 +boot: 0.470 +mistranslation: 0.433 +register: 0.396 +virtual: 0.353 +-------------------- +debug: 0.987 +x86: 0.987 +performance: 0.703 +files: 0.052 +user-level: 0.052 +PID: 0.050 +TCG: 0.048 +virtual: 0.041 +register: 0.026 +hypervisor: 0.023 +kernel: 0.018 +architecture: 0.016 +assembly: 0.014 +boot: 0.011 +semantic: 0.010 +permissions: 0.009 +device: 0.008 +graphic: 0.004 +peripherals: 0.003 +ppc: 0.003 +network: 0.003 +mistranslation: 0.002 +VMM: 0.001 +socket: 0.001 +risc-v: 0.001 +KVM: 0.001 +vnc: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-system-x86_64: stuck on watchpoint hit +Description of problem: + +Steps to reproduce: +1. `gcc -O0 -g watch-bug.c -o watch-bug` +2. `gdb watch-bug` +3. gdb commands: +``` +b main +r +watch l1 +next [ correct stop on the next line ] +next [ qemu is stuck as watchpoint should be hit ] +``` +Additional information: +* NOTE: it works correctly, if 'continue' command is used instead of 'next' + + +`watch-bug.c` +```c +int i0; +long l1; + + +int main(int argc, char* argv[]) +{ + i0 = argc; + l1 = i0 * 7; + + return 0; +} + +``` + +Log: +```c +Log: +root@qemux86-64:~# gdb watch-bug +GNU gdb (GDB) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-poky-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from watch-bug... +(gdb) b main +Breakpoint 1 at 0x1134: file watch-bug.c, line 8. +(gdb) r +Starting program: /home/root/watch-bug +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". + +Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8 +8 i0 = argc; +(gdb) watch l1 +Hardware watchpoint 2: l1 +(gdb) next +9 l1 = i0 * 7; +(gdb) next +``` diff --git a/results/classifier/118/architecture-x86/2383 b/results/classifier/118/architecture-x86/2383 new file mode 100644 index 000000000..f88499d09 --- /dev/null +++ b/results/classifier/118/architecture-x86/2383 @@ -0,0 +1,63 @@ +x86: 0.948 +architecture: 0.802 +device: 0.726 +arm: 0.521 +network: 0.483 +performance: 0.470 +boot: 0.340 +register: 0.297 +mistranslation: 0.291 +graphic: 0.277 +socket: 0.270 +kernel: 0.263 +hypervisor: 0.185 +semantic: 0.178 +permissions: 0.176 +files: 0.170 +virtual: 0.155 +risc-v: 0.149 +i386: 0.146 +peripherals: 0.129 +ppc: 0.126 +PID: 0.117 +VMM: 0.109 +TCG: 0.108 +vnc: 0.093 +KVM: 0.077 +assembly: 0.065 +user-level: 0.063 +debug: 0.049 +-------------------- +x86: 0.998 +i386: 0.824 +virtual: 0.783 +kernel: 0.347 +architecture: 0.090 +assembly: 0.052 +files: 0.045 +hypervisor: 0.031 +device: 0.029 +semantic: 0.020 +peripherals: 0.011 +debug: 0.010 +boot: 0.010 +socket: 0.008 +register: 0.007 +user-level: 0.007 +KVM: 0.006 +graphic: 0.002 +TCG: 0.001 +network: 0.001 +performance: 0.001 +permissions: 0.001 +PID: 0.001 +risc-v: 0.001 +VMM: 0.001 +vnc: 0.000 +mistranslation: 0.000 +ppc: 0.000 +arm: 0.000 + +Support SMRR for x86 emulation +Additional information: + diff --git a/results/classifier/118/architecture-x86/2531 b/results/classifier/118/architecture-x86/2531 new file mode 100644 index 000000000..876dc5218 --- /dev/null +++ b/results/classifier/118/architecture-x86/2531 @@ -0,0 +1,120 @@ +x86: 0.950 +architecture: 0.933 +device: 0.898 +files: 0.879 +arm: 0.869 +user-level: 0.849 +PID: 0.751 +debug: 0.747 +graphic: 0.729 +risc-v: 0.728 +performance: 0.727 +boot: 0.699 +vnc: 0.681 +socket: 0.656 +semantic: 0.625 +kernel: 0.611 +ppc: 0.595 +register: 0.519 +network: 0.501 +permissions: 0.495 +TCG: 0.485 +VMM: 0.464 +KVM: 0.353 +mistranslation: 0.347 +hypervisor: 0.341 +i386: 0.210 +assembly: 0.191 +peripherals: 0.190 +virtual: 0.125 +-------------------- +x86: 0.981 +debug: 0.746 +TCG: 0.465 +register: 0.239 +PID: 0.220 +files: 0.104 +virtual: 0.091 +boot: 0.066 +architecture: 0.031 +kernel: 0.022 +hypervisor: 0.019 +device: 0.019 +user-level: 0.018 +VMM: 0.017 +performance: 0.011 +network: 0.010 +assembly: 0.009 +semantic: 0.005 +graphic: 0.005 +peripherals: 0.005 +permissions: 0.004 +vnc: 0.003 +socket: 0.003 +ppc: 0.003 +risc-v: 0.001 +arm: 0.001 +KVM: 0.001 +mistranslation: 0.001 +i386: 0.000 + +QEMU internal SIGSEGV when creating an x86_64 Debian chroot from an aarch64 host. +Description of problem: +When I try to create a x86_64 Debian chroot using debootstrap from an aarch64 host system, QEMU segfaults causing the process to fail. +Steps to reproduce: +1. Run `sudo apt install debootstrap qemu-user-static binfmt-support` +2. Run `sudo debootstrap --arch amd64 bookworm debian_chroot http://deb.debian.org/debian/` +Additional information: +End of deboostrap output: +``` +I: Configuring dash... +I: Configuring libpam-modules:amd64... +I: Configuring grep... +I: Configuring perl-base... +I: Configuring gzip... +I: Configuring passwd... +I: Configuring login... +I: Configuring apt... +I: Configuring adduser... +I: Configuring libc-bin... +W: Failure while configuring required packages. +W: See /home/allen/debian_chroot/debootstrap/debootstrap.log for details (possibly the package passwd is at fault) +``` + +End of debootstrap log: +``` +$ tail /home/allen/debian_chroot/debootstrap/debootstrap.log -n30 +Setting up grep (3.8-5) ... +Setting up perl-base (5.36.0-7+deb12u1) ... +Setting up gzip (1.12-1) ... +Setting up passwd (1:4.13+dfsg1-1+b1) ... +x86_64-binfmt-P: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +groupadd: group 'shadow' already exists +Group ID 42 has been allocated for the shadow group. You have either +used 42 yourself or created a shadow group with a different ID. +Please correct this problem and reconfigure with dpkg --configure passwd''. + +Note that both user and group IDs in the range 0-99 are globally +allocated by the Debian project and must be the same on every Debian +system. +dpkg: error processing package passwd (--configure): + installed passwd package post-installation script subprocess returned error exit status 1 +Setting up libpam-runtime (1.5.2-6+deb12u1) ... +Setting up login (1:4.13+dfsg1-1+b1) ... +dpkg: apt: dependency problems, but configuring anyway as you requested: + apt depends on adduser. + +Setting up apt (2.6.1) ... +dpkg: adduser: dependency problems, but configuring anyway as you requested: + adduser depends on passwd; however: + Package passwd is not configured yet. + +Setting up adduser (3.134) ... +Processing triggers for libc-bin (2.36-9+deb12u7) ... +Errors were encountered while processing: + passwd +``` + +Full debootstrap log: +[debootstrap.log](/uploads/4eb24abd98a647e08bd03deea897b9dd/debootstrap.log) diff --git a/results/classifier/118/architecture-x86/2578 b/results/classifier/118/architecture-x86/2578 new file mode 100644 index 000000000..6d92130d0 --- /dev/null +++ b/results/classifier/118/architecture-x86/2578 @@ -0,0 +1,74 @@ +x86: 0.998 +architecture: 0.922 +graphic: 0.890 +TCG: 0.881 +i386: 0.817 +device: 0.814 +KVM: 0.776 +kernel: 0.765 +network: 0.664 +socket: 0.644 +vnc: 0.579 +arm: 0.557 +peripherals: 0.554 +semantic: 0.512 +ppc: 0.499 +performance: 0.483 +PID: 0.444 +risc-v: 0.429 +register: 0.377 +boot: 0.365 +assembly: 0.347 +permissions: 0.323 +VMM: 0.322 +debug: 0.279 +mistranslation: 0.272 +files: 0.200 +hypervisor: 0.185 +user-level: 0.115 +virtual: 0.077 +-------------------- +x86: 1.000 +i386: 0.998 +kernel: 0.882 +TCG: 0.773 +debug: 0.575 +register: 0.094 +semantic: 0.066 +KVM: 0.055 +assembly: 0.054 +files: 0.037 +architecture: 0.030 +hypervisor: 0.027 +performance: 0.027 +device: 0.013 +user-level: 0.008 +peripherals: 0.006 +PID: 0.006 +VMM: 0.005 +virtual: 0.005 +boot: 0.003 +network: 0.002 +graphic: 0.001 +permissions: 0.001 +socket: 0.001 +ppc: 0.001 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +x86: exception during hardware interrupt pushes wrong error code +Description of problem: +Exceptions during IDT traversal push the wrong error code when triggered by a hardware interrupt. +The EXT bit in TCG mode is never set. However, it works fine in KVM mode as hardware is generating the number. +Steps to reproduce: +1. load a short IDT e.g. with 64 entries +2. trigger a self IPI through the LAPIC with a vector 100 +3. the pushed error code is 802 instead of 803. +Additional information: +It can be fixed in the lines `raise_exception_err(env, EXCP0D_GPF, intno * 8 + 2);` in `seg_helper.c` +which must include the `is_hw` field when calculating the error number. Something like `intno * 8 + 2 + (is_hw != 0)` +works here. + +Nevertheless, all the other exception cases in the `do_interrupt_*` functions have to set the same bit as well. diff --git a/results/classifier/118/architecture-x86/2891 b/results/classifier/118/architecture-x86/2891 new file mode 100644 index 000000000..eadf04fe0 --- /dev/null +++ b/results/classifier/118/architecture-x86/2891 @@ -0,0 +1,61 @@ +x86: 0.959 +device: 0.872 +architecture: 0.813 +performance: 0.736 +network: 0.736 +graphic: 0.483 +permissions: 0.433 +arm: 0.417 +socket: 0.390 +files: 0.379 +debug: 0.351 +semantic: 0.346 +register: 0.333 +peripherals: 0.327 +kernel: 0.264 +assembly: 0.235 +boot: 0.232 +hypervisor: 0.188 +VMM: 0.136 +virtual: 0.117 +mistranslation: 0.115 +PID: 0.114 +ppc: 0.110 +TCG: 0.078 +user-level: 0.060 +vnc: 0.057 +risc-v: 0.032 +KVM: 0.005 +i386: 0.005 +-------------------- +virtual: 0.965 +hypervisor: 0.917 +x86: 0.917 +debug: 0.590 +KVM: 0.083 +performance: 0.073 +user-level: 0.030 +assembly: 0.026 +kernel: 0.025 +semantic: 0.022 +files: 0.013 +PID: 0.009 +TCG: 0.008 +device: 0.007 +register: 0.006 +architecture: 0.005 +VMM: 0.004 +graphic: 0.003 +ppc: 0.002 +i386: 0.002 +boot: 0.001 +socket: 0.001 +peripherals: 0.001 +network: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +permissions: 0.000 +vnc: 0.000 +arm: 0.000 + +qemu-system-x86_64 segfaults when executing ipxe selftests diff --git a/results/classifier/118/architecture-x86/2914 b/results/classifier/118/architecture-x86/2914 new file mode 100644 index 000000000..ed6bd8e9b --- /dev/null +++ b/results/classifier/118/architecture-x86/2914 @@ -0,0 +1,75 @@ +x86: 0.987 +architecture: 0.942 +arm: 0.918 +graphic: 0.911 +device: 0.874 +semantic: 0.764 +ppc: 0.645 +performance: 0.644 +debug: 0.514 +hypervisor: 0.436 +PID: 0.434 +risc-v: 0.410 +user-level: 0.398 +socket: 0.393 +permissions: 0.385 +vnc: 0.353 +network: 0.347 +register: 0.346 +files: 0.344 +boot: 0.288 +peripherals: 0.268 +mistranslation: 0.237 +TCG: 0.229 +virtual: 0.226 +VMM: 0.203 +kernel: 0.126 +i386: 0.105 +assembly: 0.056 +KVM: 0.022 +-------------------- +x86: 0.989 +virtual: 0.399 +debug: 0.260 +files: 0.053 +performance: 0.038 +risc-v: 0.033 +user-level: 0.020 +register: 0.020 +TCG: 0.017 +PID: 0.017 +device: 0.016 +hypervisor: 0.010 +i386: 0.009 +semantic: 0.006 +network: 0.005 +kernel: 0.005 +architecture: 0.004 +arm: 0.004 +boot: 0.004 +VMM: 0.003 +assembly: 0.003 +peripherals: 0.003 +socket: 0.002 +graphic: 0.002 +permissions: 0.002 +vnc: 0.002 +ppc: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +JRE fails (SIGSEGV) on x86 Ubuntu 24.04 LTS emulated on Apple Silicon M2 ARM +Description of problem: +JRE (HotSpot Runtime) errors with SIGSEGV on x86 Linux Ubuntu 24.04.2 LTS when it is emulated on Apple Silicon M2. In this case, JRE is being triggered by SBT that is running Scala source code. + +This could be a Qemu issue, an OpenJDK issue, an Apple issue, etc. - Let me know if this is the wrong place/not under the purview of Qemu and I'll post it somewhere else. +Steps to reproduce: +I am attempting to run a Scala project (https://github.com/ucb-bar/chipyard) on a x86 machine emulated on an Apple Silicon device. The project build flow fails on step 5 when Scala sources are compiled and run. You can reproduce the issue by running Chipyard's recommended setup flow here: + +https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/Initial-Repo-Setup.html#default-requirements-installation + +Then instead of running the given build-setup command in the tutorial, run `./build-setup.sh riscv-tools -s 3 -s 8 -s 7 -s 8 -s 9 -s 10 --use-lean-conda` in order to skip the irrelevant setup steps. + +The SBT build config is in the project's base directory under build.sbt. There is a commonSettings sequence that is inherited by each subsequent project. The flow: line 409 of common.mk is triggered by line 257 & 258 of build-setup.sh, which then triggers SBT with some arguments passed into the SBT executable. +Additional information: +Extensive crash logs and attempts to solve the issue has been documented at this issue on UTM's GitHub: https://github.com/utmapp/UTM/issues/7070 diff --git a/results/classifier/118/architecture-x86/387 b/results/classifier/118/architecture-x86/387 new file mode 100644 index 000000000..982d1a801 --- /dev/null +++ b/results/classifier/118/architecture-x86/387 @@ -0,0 +1,61 @@ +x86: 0.967 +device: 0.877 +architecture: 0.873 +debug: 0.830 +performance: 0.675 +peripherals: 0.630 +arm: 0.471 +graphic: 0.453 +network: 0.421 +semantic: 0.419 +risc-v: 0.348 +i386: 0.228 +mistranslation: 0.207 +user-level: 0.159 +permissions: 0.154 +PID: 0.152 +vnc: 0.128 +VMM: 0.123 +boot: 0.093 +TCG: 0.076 +register: 0.072 +hypervisor: 0.067 +virtual: 0.066 +kernel: 0.059 +ppc: 0.058 +assembly: 0.028 +KVM: 0.027 +files: 0.018 +socket: 0.011 +-------------------- +x86: 0.992 +i386: 0.962 +peripherals: 0.958 +device: 0.248 +user-level: 0.171 +files: 0.027 +virtual: 0.025 +kernel: 0.018 +architecture: 0.012 +semantic: 0.010 +VMM: 0.008 +performance: 0.008 +boot: 0.006 +debug: 0.005 +PID: 0.004 +register: 0.004 +socket: 0.003 +assembly: 0.003 +graphic: 0.003 +risc-v: 0.002 +TCG: 0.002 +hypervisor: 0.001 +arm: 0.001 +ppc: 0.001 +vnc: 0.001 +KVM: 0.001 +network: 0.000 +mistranslation: 0.000 +permissions: 0.000 + +SD-Card not working anymore on x86 targets diff --git a/results/classifier/118/architecture-x86/616769 b/results/classifier/118/architecture-x86/616769 new file mode 100644 index 000000000..295a7fb8b --- /dev/null +++ b/results/classifier/118/architecture-x86/616769 @@ -0,0 +1,99 @@ +architecture: 0.955 +x86: 0.903 +virtual: 0.874 +register: 0.736 +graphic: 0.711 +performance: 0.691 +semantic: 0.660 +device: 0.634 +peripherals: 0.628 +user-level: 0.578 +kernel: 0.574 +debug: 0.567 +PID: 0.533 +permissions: 0.524 +network: 0.524 +hypervisor: 0.499 +mistranslation: 0.497 +ppc: 0.463 +boot: 0.456 +socket: 0.453 +vnc: 0.424 +risc-v: 0.400 +VMM: 0.337 +KVM: 0.299 +files: 0.287 +arm: 0.276 +i386: 0.253 +TCG: 0.219 +assembly: 0.151 +-------------------- +x86: 0.931 +debug: 0.922 +virtual: 0.883 +architecture: 0.800 +kernel: 0.195 +assembly: 0.050 +hypervisor: 0.037 +TCG: 0.032 +files: 0.013 +performance: 0.011 +VMM: 0.009 +PID: 0.008 +device: 0.007 +boot: 0.007 +semantic: 0.006 +user-level: 0.006 +register: 0.006 +network: 0.003 +socket: 0.003 +peripherals: 0.002 +vnc: 0.002 +graphic: 0.001 +KVM: 0.001 +permissions: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +ppc: 0.000 +i386: 0.000 +arm: 0.000 + +interrupt problem x86_64 + +Hello. +I'm studing the x86_64 arch to port colinux to this new architecture. + +For who does not know, colinux is a port of linux that runs on windows NATIVELY. Colinux is +1) a small windows driver +2) a kernel patched +3) some windows user-space application that talk with linux kernel (network, console, ...) + +I have written the more internal part of colinux, that is the code that switch between windows and linux. +This is done saving and restore the machine state : +1) CR3 +2) IDT +3) registers + +The problem I see is that after the switch I see the reboot of my virtual machine. +I would say that the new IDT and/or CR3 is not flushed. +My code is written in asm/C so I can follow the code step by step. +I can say exactly the instruction that is broken. + +All my code runs nicely on bochs. +I don't have an x86_64 real PC. + +If someone wants to repair this bug .... I'm here. + +Paolo Minazzi + +Which version of QEMU did you use when you encountered this problem? Can you still reproduce this issue with the latest version of QEMU? + +Hello Thomas, +it happens some years ago and now I'm not able to reproduce it. +I'm sorry, +thanks again, +Paolo + + +OK, thanks a lot for your response ... so let's close this bug now. + diff --git a/results/classifier/118/architecture-x86/622367 b/results/classifier/118/architecture-x86/622367 new file mode 100644 index 000000000..1c4c15ae0 --- /dev/null +++ b/results/classifier/118/architecture-x86/622367 @@ -0,0 +1,79 @@ +x86: 0.951 +graphic: 0.911 +debug: 0.886 +performance: 0.829 +architecture: 0.806 +ppc: 0.787 +device: 0.744 +mistranslation: 0.734 +network: 0.725 +user-level: 0.717 +socket: 0.695 +PID: 0.683 +files: 0.681 +semantic: 0.663 +register: 0.658 +peripherals: 0.644 +hypervisor: 0.621 +kernel: 0.611 +i386: 0.606 +permissions: 0.600 +vnc: 0.534 +virtual: 0.489 +VMM: 0.479 +arm: 0.466 +risc-v: 0.436 +boot: 0.401 +TCG: 0.397 +assembly: 0.344 +KVM: 0.335 +-------------------- +x86: 0.971 +virtual: 0.462 +debug: 0.164 +TCG: 0.101 +files: 0.094 +hypervisor: 0.068 +assembly: 0.020 +register: 0.017 +user-level: 0.012 +boot: 0.008 +performance: 0.007 +device: 0.007 +VMM: 0.004 +network: 0.004 +kernel: 0.003 +PID: 0.003 +architecture: 0.003 +semantic: 0.002 +socket: 0.001 +graphic: 0.001 +risc-v: 0.001 +i386: 0.000 +vnc: 0.000 +permissions: 0.000 +ppc: 0.000 +peripherals: 0.000 +mistranslation: 0.000 +KVM: 0.000 +arm: 0.000 + +No BIOS MPFP structure with smp=92 and more + +qemu 0.12.2, SeaBios 0.5.1, running qemu-system-x86_64.exe with option -smp. +If smp>=92 then no MP floating point structure present in 1 Mb. This may be verified by pmemsave 0 0x100000 in debugger and search for _MP_ signature in file. + +qemu 0.10.5 (bios build 05/08/09) can smp=128 (and even 255 if not hangs :). + +Host win 7 x64 RTM 7600. + +QEMU 0.12 is quite outdated nowadays ... can you still reproduce this issue with the latest version of QEMU (currently version 2.8)? + +Man, really? xD +6 years have passed... +Close the ticket please, I don't have this code anymore. +... +still laughing... sorry + +Better late than never ;-) + diff --git a/results/classifier/118/architecture-x86/670 b/results/classifier/118/architecture-x86/670 new file mode 100644 index 000000000..ab36888dc --- /dev/null +++ b/results/classifier/118/architecture-x86/670 @@ -0,0 +1,70 @@ +x86: 0.935 +architecture: 0.923 +boot: 0.811 +performance: 0.793 +device: 0.780 +graphic: 0.723 +mistranslation: 0.613 +semantic: 0.608 +files: 0.572 +socket: 0.513 +debug: 0.503 +PID: 0.493 +vnc: 0.483 +permissions: 0.475 +network: 0.446 +arm: 0.444 +risc-v: 0.359 +register: 0.354 +i386: 0.304 +ppc: 0.298 +VMM: 0.280 +TCG: 0.274 +kernel: 0.250 +assembly: 0.217 +user-level: 0.204 +peripherals: 0.127 +virtual: 0.115 +hypervisor: 0.109 +KVM: 0.031 +-------------------- +x86: 0.954 +virtual: 0.885 +hypervisor: 0.349 +boot: 0.314 +files: 0.283 +debug: 0.096 +network: 0.040 +TCG: 0.038 +user-level: 0.027 +performance: 0.022 +socket: 0.015 +PID: 0.012 +risc-v: 0.007 +device: 0.007 +kernel: 0.006 +register: 0.005 +VMM: 0.004 +ppc: 0.002 +assembly: 0.002 +semantic: 0.002 +vnc: 0.001 +graphic: 0.001 +architecture: 0.001 +peripherals: 0.001 +permissions: 0.000 +mistranslation: 0.000 +i386: 0.000 +KVM: 0.000 +arm: 0.000 + +qemu x86_64 for microsoft windows hangs when booting a Debian Live 11.1 iso file +Description of problem: +qemu displays the boot screen from the live linux iso and starts the boot, but no more display is performed even when waiting for approximately 30 minutes +Steps to reproduce: +1. Get hold of a Live Linux iso from Debian 11.1 +2. Set up the Microsoft Windows version of qemu from https://qemu.weilnetz.de/ +3. Attempt to boot the Live Linux iso +Additional information: +I also tested older versions of QEMU from the Weilnetz web site. 6.0.0 and 5.2.0 are bad; 5.1.0 and older are good. I then tested the same command line ( no acceleration ) under Linux Tumbleweed 20211014 with qemu 6.1.0 and the iso booted successfully. I have not tried with isos from distributions other than Debian 11.1 . So there is a bug with the Microsoft Windows-specific code in qemu. +If you need the specific Live Linux that I was using, let me know and I will get it to you somehow. It is several GB in size so I cannot upload it anywhere conveniently. diff --git a/results/classifier/118/architecture-x86/705 b/results/classifier/118/architecture-x86/705 new file mode 100644 index 000000000..8120032d1 --- /dev/null +++ b/results/classifier/118/architecture-x86/705 @@ -0,0 +1,87 @@ +x86: 0.923 +device: 0.910 +graphic: 0.894 +kernel: 0.865 +performance: 0.864 +PID: 0.851 +architecture: 0.847 +peripherals: 0.827 +boot: 0.800 +register: 0.793 +mistranslation: 0.773 +user-level: 0.712 +network: 0.710 +semantic: 0.708 +socket: 0.692 +debug: 0.686 +KVM: 0.683 +ppc: 0.670 +vnc: 0.644 +files: 0.644 +risc-v: 0.568 +permissions: 0.556 +hypervisor: 0.507 +TCG: 0.490 +assembly: 0.440 +arm: 0.396 +i386: 0.376 +VMM: 0.368 +virtual: 0.313 +-------------------- +x86: 0.959 +kernel: 0.908 +virtual: 0.874 +KVM: 0.785 +register: 0.331 +hypervisor: 0.151 +debug: 0.086 +peripherals: 0.076 +TCG: 0.069 +VMM: 0.060 +device: 0.050 +files: 0.028 +PID: 0.026 +architecture: 0.025 +boot: 0.025 +risc-v: 0.013 +performance: 0.012 +semantic: 0.012 +network: 0.009 +assembly: 0.008 +ppc: 0.007 +socket: 0.005 +user-level: 0.004 +permissions: 0.003 +graphic: 0.003 +vnc: 0.002 +arm: 0.001 +i386: 0.001 +mistranslation: 0.001 + +Failed to acpi hotplug on pcie root ports in case of q35+ovmf+machine type 6.1 +Description of problem: +Hotplug on multifunction bridges use ACPI hotplug instead of Native since machine type 6.1 +In this case, Hotplug works well on q35 with bios fireware, But doesn't work on q35 with ovmf firmware. +E.g: +/usr/bin/qemu-system-x86_64 \ +-machine pc-q35-6.1,accel=kvm,pflash0=...... \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ +...... + +(qemu) netdev_add bridge,br=br0,id=hostnet1 +(qemu) device_add virtio-net-pci,netdev=hostnet1,id=net1,bus=pci.3 + +Error message in guest kernel: +kernel: pci 0000:03:00.0: [1af4:1041] type 00 class 0x020000 +kernel: pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x00000fff] +kernel: pci 0000:03:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref] +kernel: pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref] +kernel: pci 0000:03:00.0: BAR 6: no space for [mem size 0x00040000 pref] +kernel: pci 0000:03:00.0: BAR 6: failed to assign [mem size 0x00040000 pref] +kernel: pci 0000:03:00.0: BAR 4: no space for [mem size 0x00004000 64bit pref] +kernel: pci 0000:03:00.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] +kernel: pci 0000:03:00.0: BAR 1: no space for [mem size 0x00001000] +kernel: pci 0000:03:00.0: BAR 1: failed to assign [mem size 0x00001000] +kernel: virtio-pci 0000:03:00.0: virtio_pci: leaving for legacy driver diff --git a/results/classifier/118/architecture-x86/796202 b/results/classifier/118/architecture-x86/796202 new file mode 100644 index 000000000..dbf161db3 --- /dev/null +++ b/results/classifier/118/architecture-x86/796202 @@ -0,0 +1,130 @@ +architecture: 0.930 +register: 0.930 +kernel: 0.918 +x86: 0.910 +socket: 0.871 +ppc: 0.843 +graphic: 0.836 +boot: 0.813 +permissions: 0.812 +network: 0.805 +device: 0.803 +semantic: 0.794 +vnc: 0.793 +performance: 0.768 +files: 0.766 +PID: 0.733 +peripherals: 0.720 +user-level: 0.703 +mistranslation: 0.694 +risc-v: 0.644 +hypervisor: 0.633 +VMM: 0.627 +debug: 0.619 +virtual: 0.615 +assembly: 0.558 +arm: 0.539 +TCG: 0.488 +KVM: 0.478 +i386: 0.378 +-------------------- +x86: 0.992 +kernel: 0.931 +virtual: 0.909 +assembly: 0.378 +register: 0.328 +debug: 0.151 +hypervisor: 0.102 +architecture: 0.070 +network: 0.041 +PID: 0.030 +socket: 0.028 +files: 0.026 +boot: 0.022 +TCG: 0.021 +device: 0.017 +semantic: 0.014 +vnc: 0.006 +performance: 0.005 +user-level: 0.004 +permissions: 0.003 +graphic: 0.002 +peripherals: 0.002 +ppc: 0.001 +mistranslation: 0.001 +KVM: 0.001 +VMM: 0.001 +risc-v: 0.000 +i386: 0.000 +arm: 0.000 + +Doing a 64 bit load from a 32 bit local APIC register is allowed + +Doing + +u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20; + +and later in an interrupt handler + +movq (lapic_idregister), %rcx +movq (%rcx), %rcx + +in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots). +On real hardware only + +movl (%rcx), %ecx + +works (also in qemu). + +Commandline: +qemu-system-x86_64 \ + -kernel $LINUXDIR/arch/x86_64/boot/bzImage \ + -hda $BUILDROOTDIR/output/images/rootfs.ext2 \ + -append "root=/dev/sda rw rootfstype=ext2 maxcpus=4" \ + -cpu phenom \ + -smp 4 \ + -gdb tcp::1234 \ + -net nic -net user + +Guest: +Vanilla Linux Kernel 2.6.37.6 64-bit with buildroot + +Mikael Pettersson from the linux kernel mailinglist told me it's an accepts-invalid bug in qemu. + +On Sun, Jun 12, 2011 at 4:03 PM, Robert Uhl <email address hidden> wrote: +> Public bug reported: +> +> Doing +> +> u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20; +> +> and later in an interrupt handler +> +> movq (lapic_idregister), %rcx +> movq (%rcx), %rcx +> +> in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots). +> On real hardware only +> +> movl (%rcx), %ecx +> +> works (also in qemu). + +Thank you for the report. Currently QEMU devices only provide access +methods up to 32 bits, a 64 bit access is emulated with two 32 bit +accesses. So it is not possible to handle a 32 bit access differently +from a 64 bit one for now. + +So far this hasn't been considered to be a problem for x86, though it +is clearly not correct for Sparc and Alpha. This report shows that it +is necessary to add 64 bit access methods (or otherwise handle 64 bit +accesses more realistically) since x86 is also affected. + +Adding the 64 bit method would be a major refactoring though and there +are other designs possible. + + +Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), 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/architecture-x86/939443 b/results/classifier/118/architecture-x86/939443 new file mode 100644 index 000000000..795ecc6dc --- /dev/null +++ b/results/classifier/118/architecture-x86/939443 @@ -0,0 +1,67 @@ +x86: 0.952 +architecture: 0.930 +mistranslation: 0.918 +device: 0.888 +KVM: 0.863 +graphic: 0.764 +performance: 0.745 +virtual: 0.709 +semantic: 0.690 +network: 0.621 +register: 0.577 +peripherals: 0.496 +user-level: 0.467 +arm: 0.414 +boot: 0.409 +kernel: 0.406 +socket: 0.392 +files: 0.303 +hypervisor: 0.287 +permissions: 0.283 +VMM: 0.281 +vnc: 0.233 +i386: 0.232 +debug: 0.210 +PID: 0.189 +ppc: 0.168 +risc-v: 0.163 +TCG: 0.156 +assembly: 0.079 +-------------------- +virtual: 0.941 +KVM: 0.900 +user-level: 0.880 +x86: 0.390 +register: 0.049 +files: 0.026 +TCG: 0.024 +semantic: 0.019 +graphic: 0.014 +hypervisor: 0.008 +device: 0.007 +boot: 0.004 +architecture: 0.003 +debug: 0.003 +ppc: 0.003 +assembly: 0.002 +performance: 0.002 +permissions: 0.002 +PID: 0.002 +network: 0.001 +kernel: 0.001 +peripherals: 0.001 +socket: 0.001 +risc-v: 0.001 +VMM: 0.001 +mistranslation: 0.001 +vnc: 0.000 +arm: 0.000 +i386: 0.000 + +qemu-system-x86_64 can no support 1366x768 + +My laptop resolution is 1366x768, but can not support at -vga vmware the -vga std. + +$ kvm -version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + |