diff options
Diffstat (limited to 'results/classifier/118/architecture-i386')
18 files changed, 1534 insertions, 0 deletions
diff --git a/results/classifier/118/architecture-i386/1076445 b/results/classifier/118/architecture-i386/1076445 new file mode 100644 index 000000000..1363177da --- /dev/null +++ b/results/classifier/118/architecture-i386/1076445 @@ -0,0 +1,112 @@ +architecture: 0.983 +i386: 0.975 +user-level: 0.939 +files: 0.910 +performance: 0.892 +x86: 0.858 +ppc: 0.858 +PID: 0.857 +kernel: 0.839 +register: 0.831 +device: 0.818 +arm: 0.806 +peripherals: 0.805 +graphic: 0.779 +permissions: 0.724 +mistranslation: 0.700 +boot: 0.698 +semantic: 0.696 +socket: 0.690 +TCG: 0.640 +debug: 0.625 +hypervisor: 0.570 +network: 0.556 +risc-v: 0.537 +VMM: 0.504 +vnc: 0.487 +assembly: 0.471 +KVM: 0.371 +virtual: 0.340 +-------------------- +i386: 0.989 +x86: 0.980 +virtual: 0.520 +hypervisor: 0.335 +files: 0.062 +TCG: 0.032 +PID: 0.018 +register: 0.012 +debug: 0.007 +semantic: 0.006 +arm: 0.004 +architecture: 0.003 +user-level: 0.003 +kernel: 0.003 +boot: 0.003 +performance: 0.003 +device: 0.003 +network: 0.002 +VMM: 0.002 +socket: 0.001 +permissions: 0.001 +KVM: 0.001 +peripherals: 0.001 +ppc: 0.001 +risc-v: 0.001 +graphic: 0.001 +mistranslation: 0.000 +vnc: 0.000 +assembly: 0.000 + +qemu-i386 fails on system(3) with a cross-toolchain from Buildroot + +qemu-i386 fails with small C program containing a system(). +The C program is cross-compiled with a toolchain created by buildroot (http://buildroot.net/), gcc version 4.6.3, uClibc version 0.9.33.2 . +qemu version 1.2.0 (built with http://git.buildroot.net/buildroot/tree/package/qemu/qemu.mk) +host machine : Ubuntu 12.04 LTS on x86_64. + + $ cat sys.c + #include <stdio.h> + #include <stdlib.h> + + int main() + { + int ret = system("echo hello"); + printf("%d\n", ret); + } + + $ ../../host/usr/bin/i686-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-i386 ./sys + -1 + +same problem with x86_64 : + $ ../../host/usr/bin/x86_64-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-x86_64 sys + -1 + +works fine with arm : + $ ../../host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-arm ./sys + hello + 0 + +works fine with mips : + $ ../../host/usr/bin/mips-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped + $ ../../host/usr/bin/qemu-mips sys + hello + 0 + +Looks like the long-standing "clone/fork for i386 user mode targets doesn't work" issue. See also discussion in bug 739785... + + +Fixed in 2013 some time. + + diff --git a/results/classifier/118/architecture-i386/1163065 b/results/classifier/118/architecture-i386/1163065 new file mode 100644 index 000000000..1f8e801cf --- /dev/null +++ b/results/classifier/118/architecture-i386/1163065 @@ -0,0 +1,85 @@ +i386: 0.940 +architecture: 0.847 +virtual: 0.732 +boot: 0.722 +x86: 0.709 +register: 0.697 +device: 0.683 +performance: 0.677 +graphic: 0.648 +mistranslation: 0.598 +ppc: 0.584 +permissions: 0.562 +semantic: 0.560 +kernel: 0.557 +socket: 0.455 +files: 0.428 +PID: 0.423 +network: 0.422 +peripherals: 0.417 +vnc: 0.392 +assembly: 0.343 +debug: 0.284 +user-level: 0.267 +VMM: 0.239 +hypervisor: 0.238 +risc-v: 0.231 +arm: 0.211 +TCG: 0.192 +KVM: 0.086 +-------------------- +i386: 0.998 +x86: 0.997 +assembly: 0.981 +kernel: 0.844 +boot: 0.827 +debug: 0.449 +architecture: 0.265 +TCG: 0.259 +files: 0.076 +semantic: 0.031 +register: 0.022 +PID: 0.020 +performance: 0.012 +hypervisor: 0.010 +user-level: 0.009 +network: 0.007 +virtual: 0.004 +device: 0.003 +VMM: 0.002 +socket: 0.002 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +graphic: 0.001 +vnc: 0.001 +ppc: 0.001 +KVM: 0.000 +arm: 0.000 + +target-i386 cpu_get_phys_page_debug checks bits in wrong order + +In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked before CR0_PG. This means that if paging is disabled but the PAE bit has been set in CR4, cpu_get_phys_page_debug will return the wrong result (it will try to translate the address as virtual rather than using it as a physical address). + +Although this might seem like an unusual case, it in fact happens consistently when booting Linux on amd64 (from linux-2.6.32.60/arch/x86/boot/compressed/head_64.S): + + /* Enable PAE mode */ + xorl %eax, %eax + orl $(X86_CR4_PAE), %eax + movl %eax, %cr4 +[... code to set up page tables omitted ...] + /* Enter paged protected Mode, activating Long Mode */ + movl $(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected mode */ + movl %eax, %cr0 + +The most noticeable effect of this bug is that using the disassembler during this time will fetch the wrong data by trying to read from page tables that aren't there. One symptom is that booting Linux amd64 with -d in_asm will result in several "Disassembler disagrees with translator over instruction decoding" messages. + +Attached is a patch that moves the CR0_PG check to the beginning. I'm still not 100% certain that the logic of cpu_get_phys_page_debug matches cpu_x86_handle_mmu_fault, but it's a start. + + + +Can you still reproduce this problem with the latest version of QEMU? If so, could you please send a refreshed patch to the qemu-devel mailing list? We do not pick up patches from the bug tracker. Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-i386/1242963 b/results/classifier/118/architecture-i386/1242963 new file mode 100644 index 000000000..70d6fe755 --- /dev/null +++ b/results/classifier/118/architecture-i386/1242963 @@ -0,0 +1,118 @@ +i386: 0.961 +graphic: 0.915 +ppc: 0.908 +architecture: 0.900 +x86: 0.897 +user-level: 0.889 +semantic: 0.871 +performance: 0.859 +device: 0.844 +KVM: 0.821 +vnc: 0.814 +PID: 0.786 +hypervisor: 0.746 +files: 0.739 +socket: 0.732 +assembly: 0.695 +arm: 0.694 +network: 0.688 +risc-v: 0.680 +boot: 0.670 +VMM: 0.651 +register: 0.647 +kernel: 0.627 +virtual: 0.624 +permissions: 0.622 +mistranslation: 0.608 +peripherals: 0.578 +debug: 0.556 +TCG: 0.544 +-------------------- +x86: 0.971 +i386: 0.962 +virtual: 0.766 +user-level: 0.413 +debug: 0.325 +hypervisor: 0.041 +PID: 0.021 +network: 0.016 +files: 0.005 +kernel: 0.005 +TCG: 0.005 +socket: 0.004 +assembly: 0.003 +register: 0.003 +VMM: 0.003 +performance: 0.002 +KVM: 0.002 +device: 0.002 +semantic: 0.002 +vnc: 0.002 +graphic: 0.001 +architecture: 0.001 +boot: 0.001 +risc-v: 0.001 +ppc: 0.000 +permissions: 0.000 +peripherals: 0.000 +mistranslation: 0.000 +arm: 0.000 + +QEMU loadvm causes guest OS freeze + +HOST: ubuntu 13.10 x64 +GUEST: winxp sp 3 x86 + +AFFECT QEMU(tested): v1.5.2, v1.5.3, v1.6.0, v1.6.1 + +I compile QEMU by myself with "./configure --target-list=i386-softmmu && make && make install". +After installing a winxp sp3 into the qemu-system-i386 with command line: +> qemu-system-i386 -m 512 -hda xp.img -net user -net nic,model=rtl8139 -rtc base=localtime,clock=vm + +I use monitor to create a live snapshot: +> stop +> savevm xxx +> cont + +And then I load this snapshot (I also try it in commad line: -loadvm xxx): +> loadvm xxx +> cont + +After that, the windows system is freeze (don't accept any keyboard or mouse input, although I knew vcpu is still working). + +If I compile with -enable-kvm and launch qemu-system-i386 with -enable-kvm, it looks like everything works well. +I think it is a bug for qemu system. + +BTW: freeze is not appearing 100%, but in my test, 95% cases would cause system freeze. + +Hi guys, + +This bug has reported in a very long time. I have tested v1.7.0, v1.7.1 and even v2.0.0rc1, v2.0.0rc2. +The bug is still there. This is very easy to reproduce. I dunno why it is not fixed until today. + +I think living-snapshot is a very important feature for Qemu. Somebody can take a look at this issue. +Or at least, give me some tips to let me know how to fix this? + +Thanks! + + +I found something, hope this could be useful. + +(qemu) info cpus +* CPU #0: pc=0x000000008054b7f1 thread_id=20447 +(qemu) savevm x +(qemu) loadvm x +(qemu) info cpus +* CPU #0: pc=0x00000000806f69ba (halted) thread_id=20447 + + +Pinging this as I'm running into the same issue, Win7 seems to be fine as a guest, just getting this with XP (SP3). + +I'm 99% certain that 1.5.0 was still fine. I looked at the commits between that and 1.5.2 but did not really see anything obvious that could cause it. + +I have the same bug, is there any news concerning a fix? + +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-i386/1487 b/results/classifier/118/architecture-i386/1487 new file mode 100644 index 000000000..232ed8813 --- /dev/null +++ b/results/classifier/118/architecture-i386/1487 @@ -0,0 +1,65 @@ +i386: 0.962 +architecture: 0.899 +device: 0.888 +boot: 0.854 +graphic: 0.815 +performance: 0.510 +semantic: 0.445 +debug: 0.418 +x86: 0.407 +files: 0.307 +mistranslation: 0.279 +register: 0.279 +vnc: 0.229 +PID: 0.215 +user-level: 0.211 +risc-v: 0.210 +TCG: 0.168 +socket: 0.144 +arm: 0.136 +permissions: 0.107 +VMM: 0.076 +kernel: 0.074 +network: 0.074 +ppc: 0.057 +assembly: 0.051 +hypervisor: 0.048 +virtual: 0.040 +peripherals: 0.029 +KVM: 0.008 +-------------------- +i386: 0.977 +x86: 0.971 +boot: 0.969 +kernel: 0.511 +debug: 0.303 +virtual: 0.204 +TCG: 0.153 +register: 0.054 +architecture: 0.053 +semantic: 0.044 +files: 0.040 +device: 0.038 +PID: 0.037 +VMM: 0.037 +performance: 0.032 +socket: 0.028 +user-level: 0.021 +hypervisor: 0.014 +KVM: 0.012 +assembly: 0.009 +peripherals: 0.005 +network: 0.003 +graphic: 0.001 +risc-v: 0.001 +permissions: 0.001 +vnc: 0.001 +ppc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +Mac OS X 10.4-10.6 i386/x86_64 not working on Apple Silicon +Description of problem: +Mac OS X panics early in the boot process. There are no issues using later versions of macOS or the PPC architecture +Steps to reproduce: +1. trying to boot 10.4/10.5/10.6 using i368/x86_64 emulation on apple silicon diff --git a/results/classifier/118/architecture-i386/1503031 b/results/classifier/118/architecture-i386/1503031 new file mode 100644 index 000000000..3eed66a4e --- /dev/null +++ b/results/classifier/118/architecture-i386/1503031 @@ -0,0 +1,81 @@ +i386: 0.884 +architecture: 0.839 +permissions: 0.744 +semantic: 0.698 +x86: 0.692 +ppc: 0.687 +device: 0.682 +register: 0.680 +socket: 0.665 +user-level: 0.657 +graphic: 0.655 +kernel: 0.653 +peripherals: 0.652 +hypervisor: 0.643 +performance: 0.626 +network: 0.599 +files: 0.588 +assembly: 0.551 +vnc: 0.525 +mistranslation: 0.512 +PID: 0.502 +risc-v: 0.490 +TCG: 0.481 +debug: 0.467 +arm: 0.444 +boot: 0.431 +VMM: 0.425 +KVM: 0.303 +virtual: 0.286 +-------------------- +i386: 0.997 +x86: 0.994 +debug: 0.138 +kernel: 0.046 +semantic: 0.039 +files: 0.038 +register: 0.026 +TCG: 0.025 +architecture: 0.022 +virtual: 0.017 +assembly: 0.014 +hypervisor: 0.014 +PID: 0.007 +user-level: 0.003 +device: 0.003 +performance: 0.002 +risc-v: 0.002 +network: 0.002 +VMM: 0.002 +vnc: 0.001 +boot: 0.001 +ppc: 0.001 +graphic: 0.001 +permissions: 0.001 +socket: 0.001 +KVM: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 + +32-to-64-bit call gate unsupported in IA32e mode + +In particular, the lcall implementation doesn't support the 64-bit TSS. + +helper_lcall_protected (target-i386/seg_helper.c:1884) calls get_ss_esp_from_tss() on a call gate to a lower privilege level, which tries to extract a 32-bit ESP and 16-bit SS from the TSS. In IA32e mode (64-bit or compatibility mode), this instead grabs the lower 32-bits of the target RSP, and 16 of the upper bits as the SS. Additionally, several of the subsequent checks are incorrect (even if the correct stack pointer were extracted). + +This isn't a problem for interrupts since the interrupts are given their own implementation entirely, that uses get_rsp_from_tss() rather than get_ss_esp_from_tss(). + +I believe the missing logic is from the branch starting "ELSE (* current TSS is 64-bit *)" in the CALL pseudocode in the Intel manual (page 3-124 of the PDF I have). + +Reproduced at master (c0b520dfb8890294a9f8879f4759172900585995), and also as of a qemu built a year ago. + +I also suspect that qemu will incorrectly allow calls through 32-bit call gates in compatibility mode (rather than raising a GP fault --- see Intel manuals volume 3A 5-21). And I doubt 64-to-64-bit call gates work either. I haven't actually tested either of those scenarios, though, this is just from reading the code. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Looking at the commit log it looks like Andrew fixed this in commit 0aca060526d3ff9632aaed in 2018 ? + + +That looks like the corresponding fix, indeed. Let's close this ticket. + diff --git a/results/classifier/118/architecture-i386/1531352 b/results/classifier/118/architecture-i386/1531352 new file mode 100644 index 000000000..4be9b8efa --- /dev/null +++ b/results/classifier/118/architecture-i386/1531352 @@ -0,0 +1,72 @@ +i386: 0.968 +architecture: 0.899 +device: 0.738 +graphic: 0.719 +mistranslation: 0.683 +performance: 0.629 +register: 0.602 +PID: 0.591 +semantic: 0.576 +network: 0.562 +permissions: 0.541 +risc-v: 0.516 +files: 0.498 +boot: 0.472 +x86: 0.468 +kernel: 0.453 +arm: 0.449 +peripherals: 0.449 +VMM: 0.440 +vnc: 0.425 +debug: 0.419 +hypervisor: 0.415 +user-level: 0.412 +ppc: 0.400 +TCG: 0.395 +socket: 0.385 +KVM: 0.355 +virtual: 0.220 +assembly: 0.127 +-------------------- +i386: 0.959 +user-level: 0.576 +x86: 0.313 +TCG: 0.084 +semantic: 0.029 +debug: 0.025 +virtual: 0.019 +files: 0.017 +boot: 0.007 +hypervisor: 0.006 +network: 0.006 +performance: 0.004 +device: 0.004 +PID: 0.004 +architecture: 0.003 +risc-v: 0.003 +register: 0.003 +ppc: 0.003 +assembly: 0.002 +kernel: 0.002 +permissions: 0.001 +socket: 0.001 +graphic: 0.001 +peripherals: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 +VMM: 0.000 +KVM: 0.000 + +QEMU_LD_PREFIX not load correct library order in the PATH + +run qemu with QEMU_LD_PREFIX argument will not load the library in the PATH. +Ex: I use debootstrap to download the library of i386 architecture +And use -L point to the path. +But not load the library from that directory. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-i386/1630527 b/results/classifier/118/architecture-i386/1630527 new file mode 100644 index 000000000..e08c4bb44 --- /dev/null +++ b/results/classifier/118/architecture-i386/1630527 @@ -0,0 +1,78 @@ +i386: 0.985 +architecture: 0.922 +device: 0.911 +x86: 0.864 +files: 0.697 +socket: 0.624 +graphic: 0.600 +ppc: 0.591 +arm: 0.553 +debug: 0.530 +vnc: 0.484 +PID: 0.482 +kernel: 0.470 +network: 0.468 +semantic: 0.433 +permissions: 0.383 +boot: 0.371 +TCG: 0.360 +register: 0.355 +risc-v: 0.352 +assembly: 0.352 +performance: 0.345 +hypervisor: 0.338 +VMM: 0.271 +mistranslation: 0.224 +KVM: 0.112 +virtual: 0.109 +user-level: 0.104 +peripherals: 0.073 +-------------------- +i386: 0.999 +x86: 0.996 +debug: 0.495 +files: 0.177 +TCG: 0.098 +hypervisor: 0.082 +kernel: 0.059 +device: 0.037 +architecture: 0.032 +register: 0.025 +PID: 0.011 +VMM: 0.011 +virtual: 0.011 +semantic: 0.011 +boot: 0.008 +user-level: 0.008 +assembly: 0.006 +peripherals: 0.006 +performance: 0.005 +KVM: 0.005 +risc-v: 0.004 +network: 0.003 +graphic: 0.002 +ppc: 0.002 +socket: 0.002 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 +arm: 0.000 + +qemu/hw/i386/amd_iommu.c:188: possible bad shift ? + +qemu/hw/i386/amd_iommu.c:188]: (error) Shifting 32-bit value by 64 bits is undefined behaviour + +Source code is + + uint64_t mask = ((1 << length) - 1) << bitpos; + +Maybe better code + + uint64_t mask = ((1ULL << length) - 1) << bitpos; + +Thanks for reporting this bug! Looks like this has already been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1d5b128cbeeab638f772e + + +Released with v2.8 + diff --git a/results/classifier/118/architecture-i386/1639983 b/results/classifier/118/architecture-i386/1639983 new file mode 100644 index 000000000..e32116bf5 --- /dev/null +++ b/results/classifier/118/architecture-i386/1639983 @@ -0,0 +1,93 @@ +i386: 0.977 +ppc: 0.921 +graphic: 0.911 +architecture: 0.884 +device: 0.878 +user-level: 0.869 +network: 0.866 +semantic: 0.853 +mistranslation: 0.844 +debug: 0.827 +peripherals: 0.823 +x86: 0.818 +permissions: 0.816 +vnc: 0.802 +performance: 0.799 +files: 0.776 +socket: 0.750 +PID: 0.727 +register: 0.688 +boot: 0.669 +risc-v: 0.657 +VMM: 0.625 +virtual: 0.624 +hypervisor: 0.601 +TCG: 0.586 +kernel: 0.580 +arm: 0.571 +KVM: 0.409 +assembly: 0.386 +-------------------- +i386: 0.996 +x86: 0.868 +user-level: 0.642 +virtual: 0.355 +debug: 0.038 +files: 0.005 +peripherals: 0.004 +semantic: 0.004 +device: 0.004 +hypervisor: 0.004 +network: 0.003 +performance: 0.002 +TCG: 0.002 +kernel: 0.001 +PID: 0.001 +register: 0.001 +assembly: 0.001 +ppc: 0.001 +boot: 0.001 +socket: 0.001 +architecture: 0.001 +risc-v: 0.001 +vnc: 0.001 +permissions: 0.000 +graphic: 0.000 +mistranslation: 0.000 +VMM: 0.000 +arm: 0.000 +KVM: 0.000 + +e1000 EEPROM have bad checksum + +I am using qemu-system-i386 to emulate FreeDOS with e1000 nic card. + +I am using Intel PRODOS v.19.0 (latest version with E1000ODI.COM file). +E1000ODI.COM v.5.07 (140116) + +http://pclosmag.com/html/issues/201208/page11.html +Suggest that v.4.75 (120212) was/is working. +Oldest PRODOS available version seems now 18.5 (June 2013) which I have not tested yet. + +When running it, it detect: Slot 18, IRQ 11, Port C000. + +But complains: +EEPROM checksum was incorrect. + +Contact your services network supplier for a replacement. + +paul@paul89473:~$ qemu-system-i386 --version +QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu5), Copyright (c) 2003-2008 Fabrice Bellard +paul@paul89473:~$ + +I'm also seeing this issue with version 2.11. Currently Intel's oldest available is 18.4 and this version reports an invalid checksum. The E1000.dos file when loaded doesn't recognize the emulated NIC. + +I was able to get the e1000odi DOS driver to correctly detect the Intel e1000e once I added a PCIe bus, however the e1000 still reports a bad checksum as of this posting with the master branch. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-i386/1745354 b/results/classifier/118/architecture-i386/1745354 new file mode 100644 index 000000000..e1119e722 --- /dev/null +++ b/results/classifier/118/architecture-i386/1745354 @@ -0,0 +1,78 @@ +i386: 0.980 +x86: 0.944 +graphic: 0.834 +architecture: 0.831 +peripherals: 0.828 +ppc: 0.810 +device: 0.805 +user-level: 0.700 +performance: 0.610 +mistranslation: 0.576 +vnc: 0.573 +semantic: 0.559 +hypervisor: 0.553 +PID: 0.535 +permissions: 0.487 +kernel: 0.475 +files: 0.474 +network: 0.464 +socket: 0.447 +register: 0.444 +boot: 0.438 +debug: 0.423 +risc-v: 0.420 +virtual: 0.400 +assembly: 0.348 +VMM: 0.343 +arm: 0.309 +TCG: 0.275 +KVM: 0.129 +-------------------- +i386: 0.985 +x86: 0.969 +virtual: 0.903 +hypervisor: 0.656 +user-level: 0.635 +debug: 0.107 +TCG: 0.049 +files: 0.026 +semantic: 0.025 +PID: 0.012 +performance: 0.011 +device: 0.011 +socket: 0.010 +peripherals: 0.006 +network: 0.004 +kernel: 0.004 +register: 0.003 +boot: 0.003 +ppc: 0.002 +assembly: 0.002 +architecture: 0.002 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +graphic: 0.001 +arm: 0.001 +VMM: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +CDOS ps/2 mouse problem + +Qemu v2.10.2 (also tested with 2.11.0) +Host OS : CentOS 7 x86_64 (1708) +Guest OS : Concurrent DOS 386 3.0 (with GEM) + +There is my launch command : +/usr/local/bin/qemu-system-i386 -m 4m -cpu 486 -hda /home/my_user/HDD.img -vga std + +When I'm launching the guest, it is not responding after focusing in the viewer. I think this is due to the ps/2 emulation because when I add "-usb -device usb-mouse" in my command I don't have this issue (but in this case, mouse is not supported by CDOS). + +I tested with an older version of Qemu (0.11) which uses the Bochs bios (instead of SeaBios in newer versions), and I don't have this issue either. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/architecture-i386/1823831 b/results/classifier/118/architecture-i386/1823831 new file mode 100644 index 000000000..04cf0175f --- /dev/null +++ b/results/classifier/118/architecture-i386/1823831 @@ -0,0 +1,101 @@ +i386: 0.834 +hypervisor: 0.819 +architecture: 0.808 +device: 0.712 +x86: 0.705 +performance: 0.687 +boot: 0.645 +ppc: 0.586 +semantic: 0.572 +kernel: 0.561 +socket: 0.553 +network: 0.522 +PID: 0.496 +VMM: 0.493 +permissions: 0.485 +user-level: 0.464 +risc-v: 0.454 +register: 0.453 +peripherals: 0.429 +TCG: 0.407 +graphic: 0.400 +debug: 0.400 +vnc: 0.390 +files: 0.385 +mistranslation: 0.376 +virtual: 0.348 +arm: 0.326 +assembly: 0.314 +KVM: 0.239 +-------------------- +i386: 0.984 +x86: 0.964 +debug: 0.834 +boot: 0.708 +hypervisor: 0.671 +kernel: 0.182 +virtual: 0.105 +files: 0.021 +network: 0.012 +TCG: 0.009 +PID: 0.008 +register: 0.007 +device: 0.005 +user-level: 0.004 +architecture: 0.004 +semantic: 0.004 +socket: 0.003 +performance: 0.002 +assembly: 0.002 +vnc: 0.001 +risc-v: 0.001 +graphic: 0.001 +VMM: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +ppc: 0.001 +KVM: 0.000 +arm: 0.000 + +BSD bootloader halts with hypervisor.framework + +Guest: FreeBSD 12.0 Install CD +Host: MacOS 11.14.3 qemu master at 90fb864a7df0a9af677352e94f8225f7b03de922 + +Command arguments: + +qemu-system-x86_64 -m 4000m -cdrom Downloads/FreeBSD-12.0-RELEASE-amd64-bootonly.iso + +When qemu was run with -accel hvf, the bootloader would halt after showing the menu. The bootloader would not respond to any keyboard events. + +Without acceleration option, the bootloader would count down to zero and proceed. + +Git bisect shows that 92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855 is the first bad commit. + +Author: Paolo Bonzini <email address hidden> +Date: Tue Aug 21 15:31:24 2018 +0200 + + target/i386: unify masking of interrupts + + Interrupt handling depends on various flags in env->hflags or env->hflags2, + and the exact detail were not exactly replicated between x86_cpu_has_work + and x86_cpu_exec_interrupt. Create a new function that extracts the + highest-priority non-masked interrupt, and use it in both functions. + +In good versions (27e18b8952f8b7a1e26350846f8a0d5a9b33bfb8), calls to x86_cpu_has_work(), likely due to IRQ 0, returned interchanging true or false. + +In bad versions (92d5f1a4147c3722b5e9a8bcfb7dc261b7a8b855), all calls returned false. + +Hi Chen, + +Do you see the issue on the latest version of QEMU (v5.0 or master)? + +The fix addressed incorrect IRQ inhibition: +https://git.qemu.org/?p=qemu.git;a=commit;h=ddd31732a7379e056749836ff37ff57718083ddb + +Thanks, +Roman + +Yes, I've verified. It boots after countdown and responds to keyboard events. + diff --git a/results/classifier/118/architecture-i386/206818 b/results/classifier/118/architecture-i386/206818 new file mode 100644 index 000000000..1ef171563 --- /dev/null +++ b/results/classifier/118/architecture-i386/206818 @@ -0,0 +1,106 @@ +i386: 0.998 +architecture: 0.975 +device: 0.902 +kernel: 0.897 +x86: 0.849 +debug: 0.836 +ppc: 0.819 +PID: 0.802 +semantic: 0.726 +files: 0.725 +mistranslation: 0.688 +performance: 0.685 +permissions: 0.668 +user-level: 0.657 +arm: 0.655 +register: 0.574 +peripherals: 0.546 +graphic: 0.504 +network: 0.473 +risc-v: 0.433 +socket: 0.427 +TCG: 0.421 +vnc: 0.410 +hypervisor: 0.410 +VMM: 0.405 +boot: 0.246 +virtual: 0.230 +KVM: 0.144 +assembly: 0.122 +-------------------- +i386: 0.996 +user-level: 0.864 +debug: 0.279 +architecture: 0.128 +kernel: 0.057 +PID: 0.052 +register: 0.052 +x86: 0.031 +TCG: 0.026 +network: 0.012 +files: 0.011 +performance: 0.011 +device: 0.010 +semantic: 0.009 +socket: 0.008 +VMM: 0.007 +virtual: 0.006 +peripherals: 0.003 +graphic: 0.003 +boot: 0.003 +hypervisor: 0.003 +assembly: 0.002 +vnc: 0.002 +risc-v: 0.002 +KVM: 0.001 +permissions: 0.001 +mistranslation: 0.001 +ppc: 0.000 +arm: 0.000 + +qemulator.py crashed with IndexError in on_comboboxMachinetype_changed() + +Binary package hint: qemulator + +Hy + +I simply opened qemulator and than qemulator crashed said the bug report utility +but qemulator was open and work . + +i dont know were the error is but i will report it anyway . + +I use: + Ubuntu hardy (development branch) +Release: 8.04 + +qemulator version 0.5-3 + +regards peter + +ProblemType: Crash +Architecture: i386 +Date: Tue Mar 25 22:27:24 2008 +DistroRelease: Ubuntu 8.04 +ExecutablePath: /usr/share/qemulator/qemulator.py +InterpreterPath: /usr/bin/python2.5 +NonfreeKernelModules: nvidia +Package: qemulator 0.5-3 +PackageArchitecture: all +ProcCmdline: python /usr/bin/qemulator +ProcEnviron: + PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games + LANG=en_US.UTF-8 + SHELL=/bin/bash +PythonArgs: ['/usr/bin/qemulator'] +SourcePackage: qemulator +Title: qemulator.py crashed with IndexError in on_comboboxMachinetype_changed() +Traceback: + Traceback (most recent call last): + File "/usr/share/qemulator/qml_machinesetup.py", line 661, in on_comboboxMachinetype_changed + row = model[active] + IndexError: could not find tree path +Uname: Linux 2.6.24-12-386 i686 +UserGroups: adm admin audio cdrom dialout dip fax floppy lpadmin netdev plugdev powerdev sambashare scanner tape video + + + diff --git a/results/classifier/118/architecture-i386/2511 b/results/classifier/118/architecture-i386/2511 new file mode 100644 index 000000000..0d7816508 --- /dev/null +++ b/results/classifier/118/architecture-i386/2511 @@ -0,0 +1,92 @@ +i386: 0.963 +graphic: 0.902 +x86: 0.895 +performance: 0.841 +architecture: 0.828 +TCG: 0.794 +semantic: 0.722 +files: 0.520 +ppc: 0.519 +PID: 0.519 +device: 0.507 +kernel: 0.409 +socket: 0.408 +network: 0.399 +register: 0.390 +vnc: 0.359 +hypervisor: 0.349 +risc-v: 0.319 +user-level: 0.317 +peripherals: 0.297 +mistranslation: 0.295 +permissions: 0.268 +VMM: 0.268 +debug: 0.250 +arm: 0.195 +boot: 0.177 +virtual: 0.171 +KVM: 0.171 +assembly: 0.126 +-------------------- +i386: 0.998 +x86: 0.948 +TCG: 0.906 +debug: 0.793 +kernel: 0.608 +files: 0.124 +performance: 0.119 +architecture: 0.024 +register: 0.017 +hypervisor: 0.016 +PID: 0.010 +risc-v: 0.010 +virtual: 0.009 +boot: 0.006 +semantic: 0.006 +assembly: 0.005 +VMM: 0.004 +device: 0.003 +KVM: 0.002 +network: 0.001 +graphic: 0.001 +socket: 0.001 +user-level: 0.001 +ppc: 0.001 +peripherals: 0.001 +vnc: 0.001 +permissions: 0.000 +mistranslation: 0.000 +arm: 0.000 + +Regression 9.1.0rc2: target/i386/tcg/access.c:18: access_prepare_mmu: Assertion '...' failed. +Description of problem: +Executing QEMU command line crashes with + ``` +qemu-system-x86_64: ../target/i386/tcg/access.c:18: access_prepare_mmu: Assertion `size > 0 && size <= TARGET_PAGE_SIZE' failed. + ``` +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2020/download/day07.tar.gz +2. Execute with QEMU command line +Additional information: +git bisect finishes with: + ``` +8b131065080af3cf2dda04e4e190c5a74fec2f31 is the first bad commit +commit 8b131065080af3cf2dda04e4e190c5a74fec2f31 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Tue Jun 18 09:13:49 2024 +0200 + + target/i386/tcg: use X86Access for TSS access + + This takes care of probing the vaddr range in advance, and is also faster + because it avoids repeated TLB lookups. It also matches the Intel manual + better, as it says "Checks that the current (old) TSS, new TSS, and all + segment descriptors used in the task switch are paged into system memory"; + note however that it's not clear how the processor checks for segment + descriptors, and this check is not included in the AMD manual. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/seg_helper.c | 110 +++++++++++++++++++++++-------------------- + 1 file changed, 58 insertions(+), 52 deletions(-) + ``` diff --git a/results/classifier/118/architecture-i386/2597 b/results/classifier/118/architecture-i386/2597 new file mode 100644 index 000000000..2f58a1938 --- /dev/null +++ b/results/classifier/118/architecture-i386/2597 @@ -0,0 +1,61 @@ +i386: 0.977 +ppc: 0.924 +device: 0.916 +architecture: 0.910 +performance: 0.832 +graphic: 0.809 +peripherals: 0.524 +network: 0.472 +semantic: 0.411 +mistranslation: 0.382 +debug: 0.341 +user-level: 0.259 +register: 0.194 +permissions: 0.187 +arm: 0.179 +hypervisor: 0.174 +virtual: 0.158 +files: 0.108 +boot: 0.099 +assembly: 0.093 +PID: 0.092 +socket: 0.068 +VMM: 0.058 +kernel: 0.048 +risc-v: 0.036 +TCG: 0.035 +vnc: 0.032 +x86: 0.015 +KVM: 0.003 +-------------------- +ppc: 0.987 +i386: 0.986 +virtual: 0.972 +x86: 0.925 +hypervisor: 0.788 +architecture: 0.247 +user-level: 0.057 +debug: 0.034 +device: 0.025 +semantic: 0.013 +TCG: 0.010 +files: 0.009 +assembly: 0.009 +PID: 0.006 +kernel: 0.006 +performance: 0.005 +register: 0.004 +boot: 0.003 +KVM: 0.003 +graphic: 0.002 +VMM: 0.002 +peripherals: 0.002 +socket: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +arm: 0.000 +network: 0.000 +permissions: 0.000 +vnc: 0.000 + +qemu-i386 crashes on ppc64el diff --git a/results/classifier/118/architecture-i386/300 b/results/classifier/118/architecture-i386/300 new file mode 100644 index 000000000..d1a41b1bc --- /dev/null +++ b/results/classifier/118/architecture-i386/300 @@ -0,0 +1,61 @@ +i386: 0.997 +virtual: 0.912 +performance: 0.880 +device: 0.870 +architecture: 0.837 +network: 0.805 +debug: 0.755 +graphic: 0.579 +hypervisor: 0.577 +boot: 0.465 +socket: 0.400 +register: 0.399 +files: 0.367 +PID: 0.263 +x86: 0.222 +arm: 0.198 +VMM: 0.197 +semantic: 0.194 +mistranslation: 0.184 +peripherals: 0.181 +vnc: 0.169 +assembly: 0.158 +kernel: 0.143 +user-level: 0.085 +permissions: 0.081 +TCG: 0.055 +ppc: 0.029 +risc-v: 0.019 +KVM: 0.009 +-------------------- +i386: 0.999 +x86: 0.993 +virtual: 0.986 +hypervisor: 0.906 +debug: 0.441 +kernel: 0.158 +VMM: 0.080 +assembly: 0.076 +KVM: 0.030 +user-level: 0.030 +TCG: 0.029 +performance: 0.018 +semantic: 0.014 +files: 0.007 +register: 0.006 +graphic: 0.006 +device: 0.005 +PID: 0.004 +boot: 0.003 +architecture: 0.002 +risc-v: 0.001 +socket: 0.001 +network: 0.001 +peripherals: 0.001 +vnc: 0.000 +mistranslation: 0.000 +ppc: 0.000 +permissions: 0.000 +arm: 0.000 + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again diff --git a/results/classifier/118/architecture-i386/505 b/results/classifier/118/architecture-i386/505 new file mode 100644 index 000000000..8c1d73ab9 --- /dev/null +++ b/results/classifier/118/architecture-i386/505 @@ -0,0 +1,72 @@ +i386: 0.988 +graphic: 0.915 +device: 0.893 +debug: 0.871 +peripherals: 0.870 +boot: 0.849 +architecture: 0.817 +network: 0.767 +x86: 0.743 +performance: 0.699 +semantic: 0.699 +socket: 0.694 +files: 0.691 +vnc: 0.659 +permissions: 0.658 +PID: 0.624 +TCG: 0.596 +risc-v: 0.483 +user-level: 0.467 +ppc: 0.461 +hypervisor: 0.454 +mistranslation: 0.447 +register: 0.373 +kernel: 0.317 +VMM: 0.282 +arm: 0.250 +virtual: 0.096 +assembly: 0.081 +KVM: 0.080 +-------------------- +i386: 0.999 +x86: 0.998 +debug: 0.949 +hypervisor: 0.748 +TCG: 0.364 +user-level: 0.260 +files: 0.103 +network: 0.080 +register: 0.059 +PID: 0.056 +performance: 0.046 +kernel: 0.031 +virtual: 0.022 +boot: 0.021 +device: 0.017 +socket: 0.014 +assembly: 0.010 +semantic: 0.009 +risc-v: 0.008 +peripherals: 0.008 +architecture: 0.008 +graphic: 0.003 +ppc: 0.003 +VMM: 0.002 +vnc: 0.002 +permissions: 0.001 +KVM: 0.001 +mistranslation: 0.000 +arm: 0.000 + +QEMU crashes when reaching a hardware watchpoint +Description of problem: +When using hardware watchpoints, qemu crashes when it hits the watch point. +See https://github.com/zephyrproject-rtos/zephyr/issues/28613 for the same problem +Steps to reproduce: +1. Download https://download.qemu.org/qemu-6.1.0-rc0.tar.xz +2. Download debian-live-10.10.0-i386-standard.iso from https://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/ +3. Build qemu with /configure --target-list=i386-softmmu +4. Run build/qemu-system-i386 -boot d -cdrom debian-live-10.10.0-i386-standard.iso -m 512 -icount auto -gdb tcp:localhost:1234 -S -display none +5. Run gdb and inside gdb run "target remote localhost:1234" +6. In gdb, run "watch *0x0000fff0" and "cont" +7. qemu will crash with ```qemu: fatal: Raised interrupt while not in I/O function``` diff --git a/results/classifier/118/architecture-i386/788881 b/results/classifier/118/architecture-i386/788881 new file mode 100644 index 000000000..3542ff07f --- /dev/null +++ b/results/classifier/118/architecture-i386/788881 @@ -0,0 +1,79 @@ +i386: 0.947 +architecture: 0.924 +graphic: 0.867 +user-level: 0.846 +semantic: 0.828 +performance: 0.762 +register: 0.743 +device: 0.740 +x86: 0.721 +PID: 0.680 +mistranslation: 0.623 +ppc: 0.618 +files: 0.601 +debug: 0.550 +network: 0.519 +vnc: 0.467 +arm: 0.431 +boot: 0.423 +hypervisor: 0.395 +socket: 0.392 +virtual: 0.387 +TCG: 0.349 +risc-v: 0.321 +permissions: 0.319 +peripherals: 0.314 +VMM: 0.283 +assembly: 0.180 +kernel: 0.066 +KVM: 0.044 +-------------------- +i386: 0.987 +x86: 0.954 +files: 0.252 +debug: 0.055 +TCG: 0.032 +PID: 0.022 +virtual: 0.021 +user-level: 0.020 +register: 0.014 +hypervisor: 0.011 +kernel: 0.011 +architecture: 0.007 +assembly: 0.006 +boot: 0.005 +device: 0.004 +semantic: 0.004 +VMM: 0.003 +performance: 0.002 +network: 0.002 +graphic: 0.002 +socket: 0.002 +permissions: 0.001 +peripherals: 0.001 +vnc: 0.001 +KVM: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +ppc: 0.000 +arm: 0.000 + +i386-bsd-user and similar don't build on Mac OS X + +0.14.1 crashes on Mac OS X 64bit with some targets (*-bsd-user): + + CC i386-bsd-user/cpu-exec.o +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c: In function ‘cpu_x86_signal_handler’: +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: ‘REG_RIP’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: (Each undeclared identifier is reported only once +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: for each function it appears in.) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: ‘REG_TRAPNO’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: ‘REG_ERR’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:899: error: dereferencing pointer to incomplete type +make[1]: *** [cpu-exec.o] Error 1 + +The bsd-user target is currently unmainted in QEMU, and I think it is not meant for Mac OS X, but rather for FreeBSD and friends. So let's close this ticket now... + diff --git a/results/classifier/118/architecture-i386/982 b/results/classifier/118/architecture-i386/982 new file mode 100644 index 000000000..c5ae8e189 --- /dev/null +++ b/results/classifier/118/architecture-i386/982 @@ -0,0 +1,97 @@ +architecture: 0.911 +i386: 0.863 +x86: 0.855 +performance: 0.825 +device: 0.761 +user-level: 0.745 +kernel: 0.661 +semantic: 0.651 +ppc: 0.543 +vnc: 0.537 +graphic: 0.527 +assembly: 0.499 +debug: 0.484 +PID: 0.473 +TCG: 0.458 +peripherals: 0.456 +risc-v: 0.454 +arm: 0.447 +VMM: 0.435 +network: 0.432 +hypervisor: 0.382 +mistranslation: 0.366 +boot: 0.362 +socket: 0.269 +files: 0.259 +virtual: 0.239 +KVM: 0.221 +register: 0.203 +permissions: 0.188 +-------------------- +user-level: 0.934 +debug: 0.853 +i386: 0.518 +x86: 0.488 +virtual: 0.260 +files: 0.122 +TCG: 0.078 +hypervisor: 0.054 +kernel: 0.047 +ppc: 0.027 +architecture: 0.021 +PID: 0.019 +register: 0.018 +semantic: 0.013 +KVM: 0.012 +performance: 0.011 +device: 0.007 +VMM: 0.005 +network: 0.005 +arm: 0.003 +assembly: 0.003 +socket: 0.003 +peripherals: 0.002 +graphic: 0.002 +permissions: 0.001 +boot: 0.001 +vnc: 0.001 +risc-v: 0.000 +mistranslation: 0.000 + +linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine +Description of problem: +With `--strace`, the arguments to `writev` appear to be decoded incorrectly. +The syscall still succeeds and has the expected effects. +Steps to reproduce: +``` +$ cat main.c +#include <sys/uio.h> + +int main(void) { + struct iovec iov; + iov.iov_base = "hello, world!\n"; + iov.iov_len = 14; + return writev(1, &iov, 1); +} + +$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c + +$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c + +$ i686-pc-linux-gnu-gcc -static -o i686-main main.c + +$ ./i686-main +hello, world! + +$ strace ./i686-main |& grep writev +writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! + +$ qemu-i386 --strace ./i686-main |& grep writev +21953 writev(1,0x407ffe54,0x1) = 14 + +$ qemu-x86_64 --strace ./x86_64-main |& grep writev +22218 writev(1,(nil),0x407ffcc0) = 14 + +$ qemu-aarch64 --strace ./aarch64-main |& grep writev +22523 writev(1,(nil),0x407ffcc8) = 14 +``` diff --git a/results/classifier/118/architecture-i386/984 b/results/classifier/118/architecture-i386/984 new file mode 100644 index 000000000..989f0cab4 --- /dev/null +++ b/results/classifier/118/architecture-i386/984 @@ -0,0 +1,83 @@ +i386: 0.938 +device: 0.870 +architecture: 0.831 +performance: 0.807 +semantic: 0.790 +network: 0.753 +socket: 0.751 +files: 0.735 +PID: 0.720 +vnc: 0.711 +ppc: 0.706 +kernel: 0.697 +x86: 0.686 +permissions: 0.678 +graphic: 0.657 +register: 0.624 +debug: 0.616 +arm: 0.608 +risc-v: 0.591 +boot: 0.586 +TCG: 0.584 +VMM: 0.498 +assembly: 0.462 +hypervisor: 0.395 +user-level: 0.384 +peripherals: 0.375 +KVM: 0.336 +virtual: 0.312 +mistranslation: 0.140 +-------------------- +i386: 0.999 +x86: 0.975 +debug: 0.640 +TCG: 0.142 +assembly: 0.113 +virtual: 0.073 +files: 0.066 +register: 0.050 +hypervisor: 0.046 +performance: 0.029 +PID: 0.026 +semantic: 0.015 +architecture: 0.012 +device: 0.011 +kernel: 0.009 +user-level: 0.008 +network: 0.004 +peripherals: 0.004 +VMM: 0.004 +boot: 0.003 +graphic: 0.003 +ppc: 0.003 +risc-v: 0.003 +socket: 0.002 +vnc: 0.002 +permissions: 0.002 +KVM: 0.001 +mistranslation: 0.001 +arm: 0.000 + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 |