diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-12 09:56:59 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-12 09:56:59 +0200 |
| commit | b89a938452613061c0f1f23e710281cf5c83cb29 (patch) | |
| tree | d5faecfd167e088848cad894f8dc9cfef3352e3b /results/classifier/semantic-bugs/instruction | |
| parent | 7b681b9f9eedaad2f081ae11a32f459f5a1312ff (diff) | |
| download | qemu-analysis-b89a938452613061c0f1f23e710281cf5c83cb29.tar.gz qemu-analysis-b89a938452613061c0f1f23e710281cf5c83cb29.zip | |
add manually reviewed semantic bugs
Diffstat (limited to 'results/classifier/semantic-bugs/instruction')
62 files changed, 2563 insertions, 0 deletions
diff --git a/results/classifier/semantic-bugs/instruction/1057 b/results/classifier/semantic-bugs/instruction/1057 new file mode 100644 index 000000000..5815e3deb --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1057 @@ -0,0 +1,36 @@ +instruction: 0.938 +semantic: 0.521 +device: 0.491 +other: 0.379 +assembly: 0.282 +graphic: 0.233 +network: 0.207 +mistranslation: 0.133 +socket: 0.065 +KVM: 0.060 +vnc: 0.056 +boot: 0.050 + +AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions +Description of problem: +I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction: +`0x0000000000000000: C3 44 00 B8 str w3, [x6], #4` + +notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting. + +Here is the relevant part of the manual: + +``` +For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts: +• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback). +``` + +However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions. + +Another example of instruction: `0x00000000000002f8: 01 1C 40 38 ldrb w1, [x0, #1]!` +Steps to reproduce: +1. Run some hypervisor in EL2 +2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP) +3. Observe the value of ESR_EL2 on data abort + +Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch. diff --git a/results/classifier/semantic-bugs/instruction/1062 b/results/classifier/semantic-bugs/instruction/1062 new file mode 100644 index 000000000..67d2da1cb --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1062 @@ -0,0 +1,29 @@ +instruction: 0.925 +graphic: 0.906 +assembly: 0.851 +device: 0.826 +mistranslation: 0.798 +socket: 0.727 +network: 0.651 +semantic: 0.646 +vnc: 0.606 +other: 0.562 +boot: 0.478 +KVM: 0.082 + +AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32 +Description of problem: +In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support. + +This would break this EL3 code, which should run on cpu reset to attempt to return to EL1: +```asm +mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked +mov SPSR_EL3, x1 +adr x1, 1f +msr ELR_EL3, x1 +eret +1: +; something something +``` +Additional information: + diff --git a/results/classifier/semantic-bugs/instruction/1079080 b/results/classifier/semantic-bugs/instruction/1079080 new file mode 100644 index 000000000..c3723248d --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1079080 @@ -0,0 +1,43 @@ +instruction: 0.967 +graphic: 0.903 +device: 0.901 +semantic: 0.833 +network: 0.755 +socket: 0.707 +vnc: 0.648 +boot: 0.648 +other: 0.637 +mistranslation: 0.619 +assembly: 0.187 +KVM: 0.100 + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic + +It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009. + +Can you make the test case dtb and image available? That would help in testing... + + + + + + +Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/ + +If you'd like to give me a name/email [format "Full Name <email address hidden>"] I can credit you in a Reported-by: tag in the commit message... + + +You are welcome. +Credit info you need: Cesson Vincent <email address hidden> +Thank you for fixing it! + diff --git a/results/classifier/semantic-bugs/instruction/1092 b/results/classifier/semantic-bugs/instruction/1092 new file mode 100644 index 000000000..544940be7 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1092 @@ -0,0 +1,27 @@ +instruction: 0.963 +mistranslation: 0.914 +device: 0.801 +graphic: 0.636 +semantic: 0.492 +network: 0.383 +other: 0.340 +vnc: 0.339 +boot: 0.313 +socket: 0.296 +assembly: 0.171 +KVM: 0.030 + +PPC: `sraw` instructions does not set `ca` and `ca32` flags. +Description of problem: +The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to +[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should. +Additional information: +This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`). + +**sraw** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914 + +**srawi** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924 diff --git a/results/classifier/semantic-bugs/instruction/1095857 b/results/classifier/semantic-bugs/instruction/1095857 new file mode 100644 index 000000000..a74648b9b --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1095857 @@ -0,0 +1,29 @@ +instruction: 0.914 +mistranslation: 0.764 +graphic: 0.736 +device: 0.679 +other: 0.555 +semantic: 0.442 +network: 0.323 +assembly: 0.286 +socket: 0.242 +boot: 0.214 +vnc: 0.198 +KVM: 0.114 + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +end up executing as + +mov eax,[r15] + +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. + +You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/semantic-bugs/instruction/1156 b/results/classifier/semantic-bugs/instruction/1156 new file mode 100644 index 000000000..83908c6d9 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1156 @@ -0,0 +1,14 @@ +instruction: 0.874 +mistranslation: 0.834 +device: 0.815 +assembly: 0.455 +graphic: 0.452 +semantic: 0.202 +boot: 0.139 +network: 0.079 +other: 0.068 +socket: 0.017 +KVM: 0.017 +vnc: 0.007 + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/semantic-bugs/instruction/1204 b/results/classifier/semantic-bugs/instruction/1204 new file mode 100644 index 000000000..e47ce874a --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1204 @@ -0,0 +1,42 @@ +instruction: 0.457 +device: 0.406 +graphic: 0.397 +semantic: 0.357 +network: 0.356 +socket: 0.345 +assembly: 0.330 +vnc: 0.306 +mistranslation: 0.284 +other: 0.165 +boot: 0.147 +KVM: 0.125 + +AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0 +Description of problem: +As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119). +Memory regions marked as Device do not support unaligned access. +Steps to reproduce: +Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault) +``` +.balign 8 +.global first_variable +first_variable: + .word 0x1 +.balign 4 +.global second_variable +second_variable: + .word 0x2 + +no_mmu_sctlr: .dword 0x0000000030C51834 + +.globl reproducer +reproducer: + ldr x1, no_mmu_sctlr // A=0,M=0 + msr sctlr_el3, x1 + dsb sy + isb + + ldr x0, =first_variable + ldr x1, [x0, #0] // Aligned - Success + ldr x1, [x0, #4] // Unaligned - Success??? (Should be failure) +``` diff --git a/results/classifier/semantic-bugs/instruction/1245543 b/results/classifier/semantic-bugs/instruction/1245543 new file mode 100644 index 000000000..99966ab81 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1245543 @@ -0,0 +1,43 @@ +instruction: 0.966 +other: 0.798 +device: 0.770 +semantic: 0.629 +socket: 0.619 +network: 0.548 +vnc: 0.529 +graphic: 0.455 +boot: 0.437 +mistranslation: 0.417 +assembly: 0.269 +KVM: 0.262 + +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/semantic-bugs/instruction/1248168 b/results/classifier/semantic-bugs/instruction/1248168 new file mode 100644 index 000000000..22e04de30 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1248168 @@ -0,0 +1,42 @@ +instruction: 0.820 +graphic: 0.800 +assembly: 0.749 +device: 0.731 +mistranslation: 0.533 +socket: 0.270 +boot: 0.257 +other: 0.250 +semantic: 0.231 +vnc: 0.131 +network: 0.118 +KVM: 0.030 + +MIPS, self-modifying code and uncached memory + +Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region. + +For example, when running this code I get unexpected behavior: + + 0: e3000010 b 0x390 + 4: 00000000 nop + ... + 380: 00701f40 mfc0 ra,c0_epc + 384: 0400e0bb swr zero,4(ra) + 388: 18000042 eret + 38c: 00000000 nop + 390: 25500000 move t2,zero + 394: 02000b34 li t3,0x2 + 398: 23504b01 subu t2,t2,t3 + 39c: e9003c0b j 0xcf003a4 + 3a0: 0a004a21 addi t2,t2,10 + 3a4: ffff0010 b 0x3a4 + 3a8: 00000000 nop + 3ac: 00000000 nop + + I expect that swr instruction in line 384 would change `addi t2,t2,1`0 to `nop` +This should work because no cache is used for this memory region. + +Can you please provide full reproduction steps rather than just an assembly snippet? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/semantic-bugs/instruction/1328996 b/results/classifier/semantic-bugs/instruction/1328996 new file mode 100644 index 000000000..b48ededc8 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1328996 @@ -0,0 +1,25 @@ +instruction: 0.932 +device: 0.871 +mistranslation: 0.798 +graphic: 0.713 +semantic: 0.618 +network: 0.577 +socket: 0.504 +other: 0.463 +vnc: 0.395 +boot: 0.376 +assembly: 0.134 +KVM: 0.107 + +[AArch64] - blr x30 is handled incorrectly + +Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device. + + + +I think this should already be fixed in master by commit 1b505f93bcf60 (about a month ago). Can you try a newer QEMU build, please? + + + +Thanks, Peter. I just built the latest development build, and it now passes. Sorry for the false alarm. + diff --git a/results/classifier/semantic-bugs/instruction/1376 b/results/classifier/semantic-bugs/instruction/1376 new file mode 100644 index 000000000..3f75ca7c9 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1376 @@ -0,0 +1,28 @@ +instruction: 0.954 +assembly: 0.897 +device: 0.854 +graphic: 0.701 +vnc: 0.674 +socket: 0.609 +network: 0.505 +boot: 0.489 +semantic: 0.444 +KVM: 0.243 +other: 0.223 +mistranslation: 0.191 + +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/semantic-bugs/instruction/1377 b/results/classifier/semantic-bugs/instruction/1377 new file mode 100644 index 000000000..f3d87d4fe --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1377 @@ -0,0 +1,27 @@ +instruction: 0.973 +assembly: 0.847 +device: 0.773 +vnc: 0.768 +graphic: 0.742 +boot: 0.462 +socket: 0.412 +KVM: 0.326 +semantic: 0.321 +network: 0.279 +other: 0.095 +mistranslation: 0.073 + +x86 CVT* series instructions fault +Description of problem: +For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + mmap(0x555555559000, 0x1000, flag, ~~, 0); + asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); +} +``` +2. Execute. QEMU crashes but CPU does not. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs/instruction/1498 b/results/classifier/semantic-bugs/instruction/1498 new file mode 100644 index 000000000..2ac4b50f4 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1498 @@ -0,0 +1,18 @@ +instruction: 0.978 +graphic: 0.914 +other: 0.851 +device: 0.849 +semantic: 0.841 +mistranslation: 0.800 +network: 0.564 +boot: 0.371 +vnc: 0.362 +socket: 0.166 +assembly: 0.098 +KVM: 0.027 + +LDC, STC unimplemented in qemu-system-arm +Description of problem: +I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected. + +The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU. diff --git a/results/classifier/semantic-bugs/instruction/1574346 b/results/classifier/semantic-bugs/instruction/1574346 new file mode 100644 index 000000000..410bb5bab --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1574346 @@ -0,0 +1,41 @@ +instruction: 0.779 +other: 0.750 +graphic: 0.731 +device: 0.728 +mistranslation: 0.635 +semantic: 0.551 +network: 0.544 +socket: 0.467 +vnc: 0.421 +boot: 0.390 +assembly: 0.341 +KVM: 0.339 + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. + +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/semantic-bugs/instruction/1637 b/results/classifier/semantic-bugs/instruction/1637 new file mode 100644 index 000000000..9656c06fd --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1637 @@ -0,0 +1,14 @@ +instruction: 0.919 +device: 0.840 +graphic: 0.655 +boot: 0.219 +other: 0.214 +vnc: 0.201 +semantic: 0.196 +network: 0.164 +assembly: 0.162 +socket: 0.081 +mistranslation: 0.070 +KVM: 0.044 + +Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/semantic-bugs/instruction/1719984 b/results/classifier/semantic-bugs/instruction/1719984 new file mode 100644 index 000000000..909f6f0d9 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1719984 @@ -0,0 +1,27 @@ +instruction: 0.917 +graphic: 0.887 +mistranslation: 0.851 +device: 0.786 +network: 0.762 +semantic: 0.650 +boot: 0.624 +socket: 0.597 +vnc: 0.595 +KVM: 0.312 +other: 0.185 +assembly: 0.157 + +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/semantic-bugs/instruction/1737 b/results/classifier/semantic-bugs/instruction/1737 new file mode 100644 index 000000000..3b07da097 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1737 @@ -0,0 +1,62 @@ +instruction: 0.968 +graphic: 0.919 +device: 0.848 +assembly: 0.842 +socket: 0.826 +vnc: 0.774 +network: 0.701 +semantic: 0.687 +boot: 0.686 +mistranslation: 0.642 +other: 0.581 +KVM: 0.346 + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/semantic-bugs/instruction/1738434 b/results/classifier/semantic-bugs/instruction/1738434 new file mode 100644 index 000000000..e6167f2d3 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1738434 @@ -0,0 +1,50 @@ +instruction: 0.851 +socket: 0.767 +graphic: 0.763 +device: 0.757 +mistranslation: 0.729 +network: 0.680 +vnc: 0.670 +assembly: 0.666 +other: 0.625 +semantic: 0.586 +KVM: 0.558 +boot: 0.530 + +CALL FWORD PTR [ESP] handled incorrectly + +To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: + + push 33h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: + + push 23h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +0x23 is a default 32-bit selector for 32-bit processes running under WoW64. + +Environment: +QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img +Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 +Host OS: Windows 10 x64 version 1703 build 15063.786 + + + +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/semantic-bugs/instruction/1751422 b/results/classifier/semantic-bugs/instruction/1751422 new file mode 100644 index 000000000..df415ac99 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1751422 @@ -0,0 +1,71 @@ +instruction: 0.738 +mistranslation: 0.597 +semantic: 0.524 +graphic: 0.506 +socket: 0.497 +other: 0.473 +device: 0.451 +vnc: 0.425 +network: 0.386 +boot: 0.348 +assembly: 0.324 +KVM: 0.292 + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. + +Could you please provide some more information about the problem? What's exactly the error? If you've already got a patch, please have a look at https://wiki.qemu.org/Contribute/SubmitAPatch to get some information how to submit it. + +The patch is In this mail attachments, which is patch for version 2.11.1 target/i386/translate.c. +The patch is created by diff. +my English is so poor to explain how the error come, but you can see the patch result to get it. + + + + + + + + +At 2018-02-25 17:41:15, "Thomas Huth" <email address hidden> wrote: +>Could you please provide some more information about the problem? What's +>exactly the error? If you've already got a patch, please have a look at +>https://wiki.qemu.org/Contribute/SubmitAPatch to get some information +>how to submit it. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1751422 +> +>Title: +> some instructions translate error in x86 +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +> The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1751422/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + +We shouldn't really have let this expire, the submitter has a patch attached to the bug. + +Yabi: do you have a simple test program which fails without this patch and works with it? If so can you attach it to the bug ? + + +I believe this to be fixed by cfcca361d77, which is present in 2.12 but not 2.11. + +Since Richard pointed out a commit which fixed this in 2.12 and we haven't heard back from the submitter, I'm going to close this bug as fixed. + + diff --git a/results/classifier/semantic-bugs/instruction/1751494 b/results/classifier/semantic-bugs/instruction/1751494 new file mode 100644 index 000000000..2e2e48a44 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1751494 @@ -0,0 +1,38 @@ +instruction: 0.878 +graphic: 0.676 +assembly: 0.586 +device: 0.585 +semantic: 0.580 +mistranslation: 0.510 +other: 0.502 +socket: 0.335 +network: 0.320 +vnc: 0.279 +boot: 0.154 +KVM: 0.051 + +tcg-target.inc.c:3495:no such instruction: `xgetbv' + +While building QEMU on Mac OS 10.6.8 I saw this error message: +tag-target.inc.c:3495:no such instruction: `xgetbv' +In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: +asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); + +https://github.com/asmjit/asmjit/issues/78 +According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. + +Host info: +Mac OS 10.6.8 +GCC 5.2.0 + +Additional information: +This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. + +The exact commit that causes this problem is this: + +commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac +tcg/i386: Add vector operations + +This has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252 + diff --git a/results/classifier/semantic-bugs/instruction/1756927 b/results/classifier/semantic-bugs/instruction/1756927 new file mode 100644 index 000000000..3ec2692ab --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1756927 @@ -0,0 +1,47 @@ +instruction: 0.816 +device: 0.753 +boot: 0.666 +mistranslation: 0.622 +semantic: 0.554 +graphic: 0.551 +network: 0.531 +vnc: 0.523 +socket: 0.491 +assembly: 0.407 +KVM: 0.400 +other: 0.370 + +ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT + +When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception. + +You'll find attached a minimal example to reproduce the issue (just run 'make all'). +The output I get is: + +supervisor +user +prefetch +short-descriptor + +The last entry should read 'long-descriptor'. + + +Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69 +Ubuntu verison: 16.04 LTS +Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi + + + +I've just sent this patchset: +http://<email address hidden>/ +which should fix this bug and a couple of others that I noticed with our debug exception handling while I was doing that. + + +thanks Peter ! Any news on the review ? + +The patches are in master now. + + +Hi Peter, +we tested the fix and it work correctly now, thank you very much ! + diff --git a/results/classifier/semantic-bugs/instruction/1771 b/results/classifier/semantic-bugs/instruction/1771 new file mode 100644 index 000000000..3195f46f5 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1771 @@ -0,0 +1,46 @@ +instruction: 0.977 +graphic: 0.917 +device: 0.843 +socket: 0.778 +semantic: 0.749 +vnc: 0.729 +network: 0.581 +boot: 0.572 +other: 0.534 +mistranslation: 0.523 +assembly: 0.491 +KVM: 0.118 + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/semantic-bugs/instruction/1771948 b/results/classifier/semantic-bugs/instruction/1771948 new file mode 100644 index 000000000..636db688b --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1771948 @@ -0,0 +1,51 @@ +instruction: 0.898 +other: 0.852 +graphic: 0.837 +semantic: 0.818 +device: 0.763 +network: 0.610 +vnc: 0.606 +socket: 0.601 +mistranslation: 0.540 +assembly: 0.504 +boot: 0.482 +KVM: 0.408 + +aarch64 msr CNTFRQ_EL0 + +Hello, + +I'm running qemu 2.12 on a raspberry pi 3 with the command: + +qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin + +On my start file (right in the beginning with the highest EL), the following instructions: + +ldr x0 , =19200000 +msr CNTFRQ_EL0, x0 + + +and qemu halts on the "msr CNTFRQ_EL0, x0" instruction. + +I believe this is not a normal behavior. + +Thank you + +Mmm, that's not really supposed to happen. Do you have a test guest binary you can attach that I can reproduce with? + + +Looking more closely at this, I think this is because you've passed QEMU a file which it is treating as a Linux kernel. (-kernel treats raw binaries and uimage files as Linux kernels; it treats ELF files as not being Linux kernels). Linux expects to be started in EL2, so although the emulated CPU has EL3, we start your program in EL2. Your program is therefore not running at the highest available exception level, and can't write to CNTFRQ_EL0. + +For "bare metal" images where you want to do things at EL3, it may be better to build them as ELF files which are linked to load at address 0. Note that all four cores will start at address zero simultaneously, so you'll need a bit of "pen code" to sort the secondaries out from the primary. https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S might be useful reference. As I understand it, this is how your code would be run on real raspi3 hardware too. + + +Thank you for your reply. Sorry to take so long (was on vacations). + +Your comment seems correct to me. I tried with the ELF file instead of the binary file and it worked perfectly (and all the cores were running instead of just core 0). + +From my point of view, this bug can be marked as invalid. + +Thank you again. + + + diff --git a/results/classifier/semantic-bugs/instruction/1780 b/results/classifier/semantic-bugs/instruction/1780 new file mode 100644 index 000000000..354a178d0 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1780 @@ -0,0 +1,30 @@ +instruction: 0.971 +graphic: 0.882 +device: 0.724 +network: 0.589 +semantic: 0.561 +vnc: 0.436 +boot: 0.398 +socket: 0.311 +assembly: 0.172 +mistranslation: 0.130 +other: 0.041 +KVM: 0.040 + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/semantic-bugs/instruction/1790 b/results/classifier/semantic-bugs/instruction/1790 new file mode 100644 index 000000000..2a0a409bf --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1790 @@ -0,0 +1,42 @@ +instruction: 0.969 +graphic: 0.821 +boot: 0.809 +semantic: 0.738 +device: 0.730 +mistranslation: 0.585 +assembly: 0.543 +network: 0.505 +vnc: 0.500 +other: 0.437 +socket: 0.425 +KVM: 0.068 + +[AARCH64] STGP instruction is not writing the value of the second register to memory +Description of problem: +My application is built with Clang 16 and the option -fsanitize=memtag-stack. +It means the the MTE protection is activated for the stack. +The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory. +The following instruction was not working as expected: + 18004: 69000895 stgp x21, x2, [x4] +The value of the second register x2 is not transferred to the memory. +Only x21 is written. + +I think that the issue is in trans_STGP(). +We don't call finalize_memop_pair() like we do for in the general trans_STP(). + +``` +diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c +index 7d0c8f79a7..f599f3e136 100644 +--- a/target/arm/tcg/translate-a64.c ++++ b/target/arm/tcg/translate-a64.c +@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a) + + tcg_rt = cpu_reg(s, a->rt); + tcg_rt2 = cpu_reg(s, a->rt2); ++ mop = a->sz + 1; ++ mop = finalize_memop_pair(s, mop); + + assert(a->sz == 3); +``` + +With this fix, my OS (Kinibi) is now able to boot. diff --git a/results/classifier/semantic-bugs/instruction/1793608 b/results/classifier/semantic-bugs/instruction/1793608 new file mode 100644 index 000000000..b6a6faa1b --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1793608 @@ -0,0 +1,49 @@ +instruction: 0.899 +mistranslation: 0.794 +graphic: 0.781 +semantic: 0.777 +assembly: 0.747 +device: 0.645 +other: 0.636 +network: 0.605 +socket: 0.600 +vnc: 0.548 +KVM: 0.477 +boot: 0.423 + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly. + +Small clarification to the bug description above. + +Host architecture: x86_64 (AMD64) +Instructions used for building QEMU 3.0.0 from source are here: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/INSTALL + +The command line for emulating POWER9 target is below: +qemu-ppc64le -cpu POWER9 simd_test.p64_32Lp9 -c 1 + +With the workaround for lxvwsx instruction turned off (as described above) +QEMU crashes in s_test08 function of the following common SIMD test file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/test/simd_test.cpp + +A patch has been posted here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02218.html +("ppc/translate: Implement lxvwsx opcode") + +Released with QEMU v5.2.0. + diff --git a/results/classifier/semantic-bugs/instruction/1818075 b/results/classifier/semantic-bugs/instruction/1818075 new file mode 100644 index 000000000..26b345c17 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1818075 @@ -0,0 +1,133 @@ +instruction: 0.940 +graphic: 0.906 +assembly: 0.878 +other: 0.877 +device: 0.848 +KVM: 0.820 +vnc: 0.809 +network: 0.800 +semantic: 0.791 +socket: 0.778 +mistranslation: 0.773 +boot: 0.655 + +qemu x86 TCG doesn't support AVX insns + +I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. + +Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +IN: +0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 +0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx +0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx +0x4000b4ef47: 48 85 d2 testq %rdx, %rdx +0x4000b4ef4a: 79 9e jns 0x4000b4eeea + +[ hangs ] + +Attaching a gdb produces this stacktrace: + +(gdb) bt +#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 +#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 +#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 +#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 +#4 0x000055a20cfcfea8 in static_code_gen_buffer () +#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 +#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 + +<pm215> my guess is we're doing something unhelpful with the AVX insn, and so the guest code which is checking the result and using it as its loop condition for the jns is just looping forever + +<rburton> in_asm log just stopped with this as the last line +<rburton> 0x4000b4ef4a: 79 9e jns 0x4000b4eeea + + +Further debugging on IRC reveals that QEMU itself is not hanging, but the guest code is looping infinitely, because QEMU doesn't implement the AVX instruction set and isn't generating an undefined-instruction exception either. So the %rdx output from the AVX insn is wrong and the guest code never exits the loop (whose condition depends on %rdx). + +We should ideally: + * make the x86 decoder properly handle insns that don't exist for the CPU being emulated (not too difficult, but doesn't actually help in running this test program) + * implement AVX (a fair chunk of effort; it is being proposed as a GSoC project for this summer) + + +If I may be so free: + +It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. + +My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. +Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. + +If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. earlier versions of MacOS. + +Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: +-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc + +Attempting to emulate a more feature laden intel CPU results in even more issues. + +I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it. + +We do care about emulation; but as always with open source software projects, the parts that get more care and attention are the parts that people are either paid to work on or are personally interested in. x86 guest emulation in particular is not very well maintained (though it is better than some targets), because mostly people are happy to use x86 hardware, and adding support for emulation of large new architectural features like AVX is a lot of work. If you would like to help improve x86 guest emulation, you are welcome to submit patches to fix bugs or add new features. Merely saying "X should be better and you should somehow magically find three months worth of developer time to make it so" doesn't really do anything to move the situation forwards. + + +QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. Thus simply declaring that an open source project, must support something won't magically make it happen. + +IOW, the lack of coverage of newer x86 instructions is largely a reflection of the relative priorities of the current pool of contributors and where/what they feel are the best places/features to spend their time on. + +If any person does want to work on improving x86 TCG though, the project would happily receive patches, and existing contributors can offer guidance & advice along the way to help get to a successful outcome. + + +Of course it’s open source, I get that. When I say „xyz should be done“ then in the sense of „2+2 should be 4“ not in the sense of „you must implement xyz right now“ ;) + +Nonetheless, if you run e.g. on an ARM platform the command + +qemu-system-x86_64 -cpu help + +then it shouldn’t list a slew of CPUs as „available“ that clearly aren’t working. + +It should then list fully implemented CPUs separately from partially implemented CPUs (if listing them at all), and if it does list incomplete implementations, it should indicate what’s missing. +It’s just a horrible user experience, if based on such output, one spends significant time trying to get some emulation running, only to then discover from runtime error messages, that an „available“ CPU isn’t actually available. + + +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/164 + + diff --git a/results/classifier/semantic-bugs/instruction/1820686 b/results/classifier/semantic-bugs/instruction/1820686 new file mode 100644 index 000000000..f7fd19f6d --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1820686 @@ -0,0 +1,25 @@ +instruction: 0.949 +device: 0.824 +network: 0.809 +other: 0.742 +socket: 0.724 +semantic: 0.691 +vnc: 0.683 +mistranslation: 0.678 +graphic: 0.598 +boot: 0.498 +KVM: 0.321 +assembly: 0.305 + +risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' + +QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. + +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. + + + +Thanks. If you spin a full patch (ie, "git commit -s" and then "git show") I can drop it on riscv-qemu-3.1, our backports branch. Otherwise hopefully we got the bug via the decodetree conversion. + +Since this bug isn't present in the decodetree version of the riscv decoder, we might as well just close this as fix-released; we won't be doing more point-releases of QEMU versions as old as 3.1. + diff --git a/results/classifier/semantic-bugs/instruction/1824344 b/results/classifier/semantic-bugs/instruction/1824344 new file mode 100644 index 000000000..9886d36a4 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1824344 @@ -0,0 +1,71 @@ +instruction: 0.928 +assembly: 0.842 +device: 0.543 +semantic: 0.396 +network: 0.367 +socket: 0.356 +other: 0.327 +boot: 0.303 +vnc: 0.251 +graphic: 0.236 +mistranslation: 0.196 +KVM: 0.008 + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> + + + +This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler) + + +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/265 + + diff --git a/results/classifier/semantic-bugs/instruction/1824778 b/results/classifier/semantic-bugs/instruction/1824778 new file mode 100644 index 000000000..d9e3e95db --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1824778 @@ -0,0 +1,30 @@ +instruction: 0.756 +device: 0.493 +semantic: 0.280 +graphic: 0.275 +network: 0.264 +other: 0.245 +boot: 0.202 +vnc: 0.194 +socket: 0.151 +mistranslation: 0.124 +KVM: 0.054 +assembly: 0.052 + +PowerPC64: tlbivax does not work for addresses above 4G + +The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. +Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. + +I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. + +Issue can be seen in all version of QEMU. + + +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/52 + + diff --git a/results/classifier/semantic-bugs/instruction/1828867 b/results/classifier/semantic-bugs/instruction/1828867 new file mode 100644 index 000000000..05260e5d1 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1828867 @@ -0,0 +1,48 @@ +instruction: 0.527 +device: 0.454 +socket: 0.435 +mistranslation: 0.388 +assembly: 0.285 +network: 0.264 +vnc: 0.258 +graphic: 0.231 +semantic: 0.225 +boot: 0.171 +other: 0.169 +KVM: 0.124 + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" + + + +Here's also a basic test that can be run on hardware and have rflags and rsp inspected after each instruction just to see how hardware doesn't effect it. + +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. + +This is still relevant. + + +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/130 + + diff --git a/results/classifier/semantic-bugs/instruction/1832422 b/results/classifier/semantic-bugs/instruction/1832422 new file mode 100644 index 000000000..39c39a63d --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1832422 @@ -0,0 +1,33 @@ +instruction: 0.815 +device: 0.667 +network: 0.510 +socket: 0.486 +graphic: 0.457 +semantic: 0.453 +vnc: 0.413 +boot: 0.294 +other: 0.278 +mistranslation: 0.276 +assembly: 0.233 +KVM: 0.224 + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. + + + + +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/184 + + diff --git a/results/classifier/semantic-bugs/instruction/1863247 b/results/classifier/semantic-bugs/instruction/1863247 new file mode 100644 index 000000000..072da78e3 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1863247 @@ -0,0 +1,33 @@ +instruction: 0.742 +device: 0.668 +graphic: 0.540 +semantic: 0.501 +other: 0.498 +mistranslation: 0.393 +socket: 0.384 +network: 0.383 +vnc: 0.341 +boot: 0.254 +assembly: 0.250 +KVM: 0.178 + +AArch64 EXT instruction for V register does not clear MSB side bits + +On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. + +Example +ext v0.16b, v1.16b v2.16b, 8 + +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. + +Yep. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=78cedfabd53b + + +Thank you for bug fix. +I found trn1, trn2, zip1, zip2, uz1, uz2 instructions seem to have same bug. + +All of those, and tbl, tbx, ins, are fixed in the three subsequent commits. + diff --git a/results/classifier/semantic-bugs/instruction/1889288 b/results/classifier/semantic-bugs/instruction/1889288 new file mode 100644 index 000000000..4b1ea1874 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1889288 @@ -0,0 +1,26 @@ +instruction: 0.757 +mistranslation: 0.724 +semantic: 0.599 +graphic: 0.519 +assembly: 0.467 +other: 0.455 +device: 0.440 +socket: 0.381 +vnc: 0.348 +network: 0.348 +boot: 0.182 +KVM: 0.137 + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. + +The code is correct (though it is admittedly not entirely obvious at first glance). The switch statement at line 4753 is on "(opc | (invert << 2))" (where opc is a 2 bit field and invert a 1 bit field). Both ANDS and BICS have opc==3 and so will cause a call to gen_logic_CC(). The difference between the two insns is that ANDC has invert==0 and BICS has invert==1. + + +Oh yes I see. Sorry for the false report. + diff --git a/results/classifier/semantic-bugs/instruction/1898954 b/results/classifier/semantic-bugs/instruction/1898954 new file mode 100644 index 000000000..77df51de8 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1898954 @@ -0,0 +1,73 @@ +instruction: 0.923 +mistranslation: 0.880 +boot: 0.854 +graphic: 0.850 +other: 0.845 +KVM: 0.778 +device: 0.762 +semantic: 0.752 +socket: 0.648 +network: 0.624 +assembly: 0.575 +vnc: 0.567 + +x86 f1 opcode hangs qemu + +I have qemu installed and running in linux and windows +in linux i execute the following simple code in real mode of cpu in my vm +90 nop +90 nop +90 nop +f1 ;this should conjure up my interrupt handler from ivt int 1 +--------- end of code ---- +it works properly in vbox,qemu linux,and even in my boot loder +on a real platform + it doeas not work fine in windows 10 (32 bit efi) based qemu +--- +all of the below was retyped there may be typo +so onwards to the flawed software +********** for qemu-system-x86_64.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +********** for qemu-system-i386.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +*********************************************** +my startup code is +"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc +--- +also same flaw if i change above section to +"d:\programs\qemu\qemu-system-i386.exe" + +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/semantic-bugs/instruction/1901 b/results/classifier/semantic-bugs/instruction/1901 new file mode 100644 index 000000000..33ec55668 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1901 @@ -0,0 +1,32 @@ +instruction: 0.968 +graphic: 0.871 +device: 0.723 +semantic: 0.696 +other: 0.517 +network: 0.432 +socket: 0.404 +vnc: 0.392 +mistranslation: 0.243 +boot: 0.231 +assembly: 0.079 +KVM: 0.079 + +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. +Steps to reproduce: +1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. +Additional information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/semantic-bugs/instruction/1912934 b/results/classifier/semantic-bugs/instruction/1912934 new file mode 100644 index 000000000..f487e30df --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1912934 @@ -0,0 +1,78 @@ +instruction: 0.655 +device: 0.618 +semantic: 0.589 +mistranslation: 0.555 +graphic: 0.466 +socket: 0.360 +vnc: 0.325 +assembly: 0.276 +network: 0.262 +boot: 0.230 +other: 0.223 +KVM: 0.145 + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). + + + +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. + + +The situation is still the same in QEMU 6.0.0. + +$ powerpc64le-linux-gnu-gcc-5 test-fmadds.c -static +$ ~/inst-qemu/6.0.0/bin/qemu-ppc64le ./a.out ; echo $? +32 + + + +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/312 + + diff --git a/results/classifier/semantic-bugs/instruction/1915027 b/results/classifier/semantic-bugs/instruction/1915027 new file mode 100644 index 000000000..4df7ceb4b --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1915027 @@ -0,0 +1,27 @@ +instruction: 0.816 +assembly: 0.781 +graphic: 0.759 +other: 0.744 +device: 0.634 +semantic: 0.632 +mistranslation: 0.442 +vnc: 0.284 +network: 0.181 +boot: 0.140 +socket: 0.116 +KVM: 0.044 + +RISC-V 64, CPUs do ilegal 0x00 write with SMP + +When QEMU is runt like this: + +qemu-system-riscv64 -d unimp,guest_errors -smp 8 + +Other harts will do a illegal write on address 0x00. + +This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute. + +Even with -smp 1 you will see the same errors. The problem is because there is nothing to run after OpenSBI jumps to the next stage. + +If you load a kernel you will not see the error messages. + diff --git a/results/classifier/semantic-bugs/instruction/1916269 b/results/classifier/semantic-bugs/instruction/1916269 new file mode 100644 index 000000000..45a2ef615 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1916269 @@ -0,0 +1,70 @@ +instruction: 0.884 +socket: 0.821 +graphic: 0.779 +device: 0.775 +other: 0.721 +network: 0.656 +semantic: 0.654 +vnc: 0.626 +mistranslation: 0.626 +boot: 0.615 +assembly: 0.473 +KVM: 0.297 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. + +Could someone familiar with the target/i386 decode logic could have a look at this? It should be a rather simple change to avoid the exception for the crc32 encoding. However, I am not familiar with x86 instruction encodings so it would take me a long time to come up with a correct patch. +Thanks! + +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.] + +Reported on GitLab as https://gitlab.com/qemu-project/qemu/-/issues/427 + diff --git a/results/classifier/semantic-bugs/instruction/1926759 b/results/classifier/semantic-bugs/instruction/1926759 new file mode 100644 index 000000000..753b9e4d4 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1926759 @@ -0,0 +1,73 @@ +instruction: 0.938 +semantic: 0.770 +graphic: 0.694 +other: 0.656 +device: 0.644 +vnc: 0.552 +assembly: 0.506 +socket: 0.491 +network: 0.398 +boot: 0.365 +mistranslation: 0.349 +KVM: 0.297 + +WFI instruction results in unhandled CPU exception + +Hi + +I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following crash log. + +qemu: unhandled CPU exception 0x10001 - aborting +R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec +R04=00010a28 R05=00010158 R06=00087460 R07=00010158 +R08=00000000 R09=00000000 R10=00085b7c R11=408009f4 +R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8 +PSR=60000010 -ZC- A usr32 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 + +WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. + +Regards +Muhui + +Please provide a test case binary and your QEMU command line. + + +Oh, and the QEMU version you're using as well, please. + + +cmd： ~/qemu-5.1.0/arm-linux-user/qemu-arm ~/test2 + +QEMU version: qemu-arm version 5.1.0 + +Sorry that I didn't test it on the latest version of QEMU. + +Crash repros on current QEMU. + +This is a bug, in that we shouldn't crash like this. However, it doesn't really make any sense for a userspace program (which is what a binary run by qemu-arm is) to execute the WFI instruction, which is largely intended for OSes to use. If your guest binary needs to use WFI, you should probably be running it on the system emulation QEMU, which does handle WFI correctly. + + +The aarch64 kernel traps and handles WFI as a NOP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c219bc4e9205 -- so that's probably the most sensible implementation for our linux-user mode. (The aarch32 kernel doesn't trap it, yet, but +"WFI is a NOP" is a valid architectural implementation anyway.) + + +I agree with this implementation. Though WFI seems make no sense for a userspace program, we should not have assumption that the userspace program will not use this instruction. + +It seems ARM manual does not defined the implementation of function EnterLowPowerState(); However, before executing this instruction, there are some checks like below: + +if PSTATE.EL == EL0 then + // Check for traps described by the OS which may be EL1 or EL2. + AArch32.CheckForWFxTrap(EL1, FALSE); + +I am not sure whether it is complex/required to implement this in QEMU. Maybe patch the WFI as a NOP looks like the best idea at this moment. + +We do implement those traps, but only in the system mode emulator, because it makes no sense to trap to EL2 in the usermode emulator where EL2 doesn't exist. + + +Should be fixed by: +https://<email address hidden>/ + + +Fix has been merged: +https://gitlab.com/qemu-project/qemu/-/commit/5b2c8af89b82a671137a + diff --git a/results/classifier/semantic-bugs/instruction/1955 b/results/classifier/semantic-bugs/instruction/1955 new file mode 100644 index 000000000..17cd3a9de --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1955 @@ -0,0 +1,39 @@ +instruction: 0.950 +graphic: 0.840 +semantic: 0.801 +device: 0.645 +other: 0.493 +socket: 0.420 +network: 0.394 +mistranslation: 0.346 +boot: 0.280 +vnc: 0.269 +assembly: 0.183 +KVM: 0.107 + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/semantic-bugs/instruction/1958 b/results/classifier/semantic-bugs/instruction/1958 new file mode 100644 index 000000000..8240e159e --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1958 @@ -0,0 +1,34 @@ +instruction: 0.931 +mistranslation: 0.877 +graphic: 0.858 +device: 0.805 +vnc: 0.766 +semantic: 0.679 +socket: 0.488 +other: 0.383 +KVM: 0.381 +network: 0.360 +boot: 0.359 +assembly: 0.268 + +PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE] +Description of problem: +When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception. +Additional information: +In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function: + +``` +if (FIELD_EX64(env->msr, MSR, CE)) { + /* Critical doorbell */ + if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) { <- move this part from (async_deliver != 0) + return PPC_INTERRUPT_CDOORBELL; + } + /* External critical interrupt */ + if (env->pending_interrupts & PPC_INTERRUPT_CEXT) { + return PPC_INTERRUPT_CEXT; + } +} +``` + + +And it seems to work in my case. diff --git a/results/classifier/semantic-bugs/instruction/2074 b/results/classifier/semantic-bugs/instruction/2074 new file mode 100644 index 000000000..475ecd6df --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2074 @@ -0,0 +1,33 @@ +instruction: 0.908 +graphic: 0.839 +device: 0.680 +boot: 0.672 +semantic: 0.448 +other: 0.389 +mistranslation: 0.233 +vnc: 0.171 +socket: 0.147 +network: 0.129 +assembly: 0.101 +KVM: 0.093 + +riscv64 cannot use the mret instruction to jump to the address corresponding to s mode +Description of problem: +I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800. +and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened. +It shows: +[DEBUG] Exception: Instruction access fault +[DEBUG] Hart ID: 0 +[DEBUG] Previous mode: machine +[DEBUG] Bad instruction pc: 0x8103f7c0 +[DEBUG] Bad address: 0x00000000 +[DEBUG] Stored ra: 0x8103f7b8 +[DEBUG] Stored sp: 0x82032f08 +Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret". +So I can not jump to my kernel's load address. +I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address? +Steps to reproduce: +1.download qemu +2.download coreboot +Additional information: +When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000. diff --git a/results/classifier/semantic-bugs/instruction/2089 b/results/classifier/semantic-bugs/instruction/2089 new file mode 100644 index 000000000..4241b84e5 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2089 @@ -0,0 +1,40 @@ +instruction: 0.901 +semantic: 0.855 +graphic: 0.833 +device: 0.746 +vnc: 0.500 +assembly: 0.466 +network: 0.405 +socket: 0.335 +boot: 0.172 +mistranslation: 0.117 +KVM: 0.086 +other: 0.022 + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/semantic-bugs/instruction/2175 b/results/classifier/semantic-bugs/instruction/2175 new file mode 100644 index 000000000..874c3bcde --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2175 @@ -0,0 +1,51 @@ +instruction: 0.883 +device: 0.776 +graphic: 0.745 +assembly: 0.701 +network: 0.686 +vnc: 0.644 +other: 0.619 +socket: 0.611 +mistranslation: 0.593 +KVM: 0.567 +semantic: 0.514 +boot: 0.511 + +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/semantic-bugs/instruction/2248 b/results/classifier/semantic-bugs/instruction/2248 new file mode 100644 index 000000000..ae3a6196e --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2248 @@ -0,0 +1,49 @@ +instruction: 0.883 +graphic: 0.837 +assembly: 0.815 +device: 0.776 +vnc: 0.746 +network: 0.743 +socket: 0.741 +other: 0.592 +boot: 0.547 +semantic: 0.539 +KVM: 0.475 +mistranslation: 0.466 + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. diff --git a/results/classifier/semantic-bugs/instruction/2302 b/results/classifier/semantic-bugs/instruction/2302 new file mode 100644 index 000000000..dd607123b --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2302 @@ -0,0 +1,38 @@ +instruction: 0.900 +graphic: 0.787 +device: 0.692 +assembly: 0.569 +socket: 0.543 +semantic: 0.466 +vnc: 0.348 +network: 0.348 +mistranslation: 0.316 +other: 0.274 +boot: 0.240 +KVM: 0.084 + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/semantic-bugs/instruction/2317 b/results/classifier/semantic-bugs/instruction/2317 new file mode 100644 index 000000000..0acfd4575 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2317 @@ -0,0 +1,51 @@ +instruction: 0.951 +device: 0.841 +socket: 0.672 +graphic: 0.665 +vnc: 0.650 +network: 0.620 +semantic: 0.613 +assembly: 0.550 +boot: 0.545 +mistranslation: 0.480 +other: 0.332 +KVM: 0.048 + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/semantic-bugs/instruction/2318 b/results/classifier/semantic-bugs/instruction/2318 new file mode 100644 index 000000000..3defce0d6 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2318 @@ -0,0 +1,47 @@ +instruction: 0.871 +device: 0.679 +graphic: 0.495 +assembly: 0.485 +vnc: 0.479 +semantic: 0.460 +boot: 0.291 +socket: 0.281 +network: 0.239 +other: 0.133 +mistranslation: 0.100 +KVM: 0.006 + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/semantic-bugs/instruction/2386 b/results/classifier/semantic-bugs/instruction/2386 new file mode 100644 index 000000000..96e88af3c --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2386 @@ -0,0 +1,56 @@ +instruction: 0.967 +graphic: 0.899 +socket: 0.812 +device: 0.808 +vnc: 0.803 +network: 0.759 +assembly: 0.688 +mistranslation: 0.640 +semantic: 0.624 +other: 0.616 +boot: 0.615 +KVM: 0.565 + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/semantic-bugs/instruction/2497 b/results/classifier/semantic-bugs/instruction/2497 new file mode 100644 index 000000000..ccc110c51 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2497 @@ -0,0 +1,16 @@ +instruction: 0.895 +device: 0.848 +graphic: 0.685 +semantic: 0.655 +network: 0.531 +boot: 0.293 +socket: 0.291 +assembly: 0.286 +vnc: 0.283 +other: 0.236 +mistranslation: 0.145 +KVM: 0.015 + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/semantic-bugs/instruction/2500 b/results/classifier/semantic-bugs/instruction/2500 new file mode 100644 index 000000000..4939d31cc --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2500 @@ -0,0 +1,17 @@ +instruction: 0.946 +graphic: 0.818 +device: 0.817 +semantic: 0.810 +assembly: 0.807 +mistranslation: 0.739 +network: 0.738 +other: 0.715 +socket: 0.510 +boot: 0.257 +vnc: 0.154 +KVM: 0.115 + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/semantic-bugs/instruction/2865 b/results/classifier/semantic-bugs/instruction/2865 new file mode 100644 index 000000000..993bac92e --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2865 @@ -0,0 +1,65 @@ +instruction: 0.901 +assembly: 0.741 +mistranslation: 0.694 +device: 0.653 +graphic: 0.618 +socket: 0.439 +vnc: 0.390 +network: 0.364 +other: 0.326 +boot: 0.235 +semantic: 0.210 +KVM: 0.187 + +loongarch64: wrong implementation of `xvldi` instruction +Description of problem: +Consider this sample program. + +```c++ +#include <cstdio> +#include <cstdint> +#include <lsxintrin.h> +#include <lasxintrin.h> + +void dump_u32(__m256i x) { + uint32_t tmp[32/4]; + __lasx_xvst(x, tmp, 0); + putchar('['); + for (int i=0; i < 32/4; i++) { + if (i > 0) { + putchar(' '); + } + + printf("%08x", tmp[i]); + } + puts("]"); +} + +int main() { + __m256i const1 = __lasx_xvldi(-3832); + dump_u32(const1); +} +``` + +The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: + +``` +[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] +``` + +The same program run under Qemu prints: + +``` +[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] +``` +Additional information: +I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. + +```c + case 1: + /* data: {2{16'0, imm[7:0], 8'0}} */ + data = (t << 24) | (t << 8); + break; +``` + +There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/semantic-bugs/instruction/2971 b/results/classifier/semantic-bugs/instruction/2971 new file mode 100644 index 000000000..2ee49f8b8 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/2971 @@ -0,0 +1,57 @@ +instruction: 0.834 +vnc: 0.780 +device: 0.770 +assembly: 0.671 +network: 0.667 +socket: 0.623 +graphic: 0.579 +semantic: 0.515 +boot: 0.473 +other: 0.425 +KVM: 0.396 +mistranslation: 0.282 + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/semantic-bugs/instruction/361 b/results/classifier/semantic-bugs/instruction/361 new file mode 100644 index 000000000..ee26ed4b0 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/361 @@ -0,0 +1,14 @@ +instruction: 0.829 +mistranslation: 0.634 +semantic: 0.465 +graphic: 0.432 +vnc: 0.253 +device: 0.243 +boot: 0.163 +KVM: 0.134 +other: 0.106 +assembly: 0.014 +network: 0.006 +socket: 0.006 + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/semantic-bugs/instruction/390 b/results/classifier/semantic-bugs/instruction/390 new file mode 100644 index 000000000..61671b821 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/390 @@ -0,0 +1,14 @@ +instruction: 0.961 +assembly: 0.706 +device: 0.526 +graphic: 0.370 +semantic: 0.361 +boot: 0.196 +KVM: 0.175 +mistranslation: 0.162 +vnc: 0.116 +network: 0.058 +socket: 0.029 +other: 0.019 + +target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/semantic-bugs/instruction/514 b/results/classifier/semantic-bugs/instruction/514 new file mode 100644 index 000000000..f973fe24b --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/514 @@ -0,0 +1,38 @@ +instruction: 0.922 +device: 0.778 +graphic: 0.745 +semantic: 0.631 +mistranslation: 0.623 +vnc: 0.549 +assembly: 0.514 +boot: 0.468 +socket: 0.457 +network: 0.427 +other: 0.370 +KVM: 0.335 + +MTE reports false positive for "str" instruction with the SP as the base register. +Description of problem: +When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access. +Steps to reproduce: +Clang version: clang version 12.0.1. +I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code: +``` +0000000000000c14 <test_func>: + c14: a9bc7bfd stp x29, x30, [sp, #-64]! + c18: f9000bf7 str x23, [sp, #16] + ... +``` +Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch. +When cpu executes firs instruction "stp x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault": +ESR_EL1=0x96000051. + +According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access: +``` +A Tag Unchecked access will be generated for a load or store that uses either of the following: +• A base register only, with the SP as the base register. +• A base register plus immediate offset addressing form, with the SP as the base register. +``` +Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset. +Additional information: + diff --git a/results/classifier/semantic-bugs/instruction/799 b/results/classifier/semantic-bugs/instruction/799 new file mode 100644 index 000000000..b6de1812e --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/799 @@ -0,0 +1,60 @@ +instruction: 0.871 +graphic: 0.858 +assembly: 0.798 +device: 0.740 +vnc: 0.609 +socket: 0.576 +network: 0.552 +other: 0.445 +boot: 0.333 +semantic: 0.288 +mistranslation: 0.231 +KVM: 0.164 + +TCG Optimizer crashes on AArch64 SVE2 instruction +Description of problem: +QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: +``` +Unrecognized operation 145 in do_constant_folding. +../tcg/optimize.c:458: tcg fatal error +``` +Steps to reproduce: +1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) +```asm +.org 0x0 +entry: + mrs x1, cptr_el3 + orr x9, x1, #0x100 + msr cptr_el3, x9 + + msr cptr_el2, xzr + + mov x1, #0x3 + mrs x9, cpacr_el1 + bfi x9, x1, #16, #2 + bfi x9, x1, #20, #2 + msr cpacr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el2, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el3, x9 + + uqxtnt z11.s, z22.d +``` +2. Execute it using the command line given above. +Additional information: +I tested latest master as well, and the problem persists. diff --git a/results/classifier/semantic-bugs/instruction/824 b/results/classifier/semantic-bugs/instruction/824 new file mode 100644 index 000000000..cf7795167 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/824 @@ -0,0 +1,25 @@ +instruction: 0.888 +graphic: 0.848 +device: 0.834 +mistranslation: 0.623 +vnc: 0.563 +semantic: 0.474 +socket: 0.455 +assembly: 0.442 +network: 0.345 +other: 0.321 +boot: 0.225 +KVM: 0.024 + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/semantic-bugs/instruction/826 b/results/classifier/semantic-bugs/instruction/826 new file mode 100644 index 000000000..3ef3962e4 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/826 @@ -0,0 +1,29 @@ +instruction: 0.989 +graphic: 0.822 +device: 0.639 +mistranslation: 0.592 +network: 0.489 +other: 0.438 +assembly: 0.432 +semantic: 0.404 +vnc: 0.261 +socket: 0.178 +boot: 0.132 +KVM: 0.015 + +AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated +Description of problem: +During execution of the following SVE2 instruction: +`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` +with the following register state: +``` +(gdb) p $p3 +$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} +(gdb) p $z14.d.u +$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} +(gdb) p $x9 +$3 = 0x0 +``` +QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. +Additional information: +A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/semantic-bugs/instruction/925 b/results/classifier/semantic-bugs/instruction/925 new file mode 100644 index 000000000..8d42ab6dc --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/925 @@ -0,0 +1,31 @@ +instruction: 0.864 +graphic: 0.770 +device: 0.746 +network: 0.517 +other: 0.426 +assembly: 0.416 +vnc: 0.416 +socket: 0.394 +semantic: 0.338 +boot: 0.325 +KVM: 0.311 +mistranslation: 0.233 + +AArch64 SVE2 LD/ST instructions segfault on MMIO addresses +Description of problem: +During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state: +``` +(gdb) p $x17 +$1 = 0xffffffe2 +(gdb) p $z26.s.u +$2 = {0x0 <repeats 16 times>} +(gdb) p $p2 +$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0} +``` +QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device. +Additional information: +A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices. + +<details><summary>Reproducer seed for my future self</summary> +S6008340160849309262|Q|cd4t|pq|w5|lK124 +</details> diff --git a/results/classifier/semantic-bugs/instruction/984 b/results/classifier/semantic-bugs/instruction/984 new file mode 100644 index 000000000..0458e2758 --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/984 @@ -0,0 +1,36 @@ +instruction: 0.978 +device: 0.870 +semantic: 0.790 +network: 0.753 +socket: 0.751 +vnc: 0.711 +graphic: 0.657 +boot: 0.586 +assembly: 0.462 +other: 0.443 +KVM: 0.336 +mistranslation: 0.140 + +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 |