diff options
Diffstat (limited to 'results/classifier/semantic-bugs/mistranslation')
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/1613817 | 130 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/1830872 | 612 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/1861404 | 223 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/266 | 14 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/427 | 14 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/508 | 14 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/mistranslation/83 | 14 |
7 files changed, 1021 insertions, 0 deletions
diff --git a/results/classifier/semantic-bugs/mistranslation/1613817 b/results/classifier/semantic-bugs/mistranslation/1613817 new file mode 100644 index 000000000..a275fd7fb --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/1613817 @@ -0,0 +1,130 @@ +mistranslation: 0.697 +instruction: 0.679 +other: 0.653 +KVM: 0.623 +graphic: 0.617 +vnc: 0.599 +device: 0.558 +semantic: 0.550 +boot: 0.543 +assembly: 0.543 +network: 0.536 +socket: 0.523 + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack + +This test program: + +# compile with: gcc -nostartfiles -nostdlib +_start: .globl _start + mov %ss,%eax + push %rax + push %rsp + pushf + mov %cs,%eax + push %rax + mov $0x1234567812345678,%rax + push %rax +//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: + iretq +1: + jmp 1b + +should segfault on IRET instruction because return address on stack is invalid +(it is not canonical). And it does, both on native CPU and in qemu. +But there is a difference: on native CPU, it fails before instruction is executed, +IOW: saved IP points to the failed IRET: + +# strace -i ./bad_ip_in_iret +[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 +[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV (core dumped) +++ + + +In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: + +/ # strace -i ./bad_ip_in_iret +[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +Thus, the emulation is not the same as real CPU. + +This is not specific to IRET, the same happens with "far return" LRET, +and with ordinary RET instructions as well. +In qemu: + +/ # strace -i ./bad_ip_in_lret +[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault +/ # strace -i ./bad_ip_in_ret +[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +# qemu-system-x86_64 --version +QEMU emulator version 2.6.92(qemu-2.7.0-0.1.rc2.fc26), Copyright (c) 2003-2008 Fabrice Bellard + +Running it like this: + +qemu-system-x86_64 -no-reboot -kernel "$bzImage" -initrd initramfs.cpio -append "panic=1" + +(i.e. no KVM, no unusual options) + + +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. + + +Still happens with qemu 5.1.92 + +I imagine the fix should be inserted here: + +static inline void helper_ret_protected(CPUX86State *env, int shift, + int is_iret, int addend, + uintptr_t retaddr) +{ + uint32_t new_cs, new_eflags, new_ss; + uint32_t new_es, new_ds, new_fs, new_gs; + uint32_t e1, e2, ss_e1, ss_e2; + int cpl, dpl, rpl, eflags_mask, iopl; + target_ulong ssp, sp, new_eip, new_esp, sp_mask; + +#ifdef TARGET_X86_64 + if (shift == 2) { + sp_mask = -1; + } else +#endif + { + sp_mask = get_sp_mask(env->segs[R_SS].flags); + } + sp = env->regs[R_ESP]; + ssp = env->segs[R_SS].base; + new_eflags = 0; /* avoid warning */ +#ifdef TARGET_X86_64 + if (shift == 2) { + POPQ_RA(sp, new_eip, retaddr); +if (new_eip is not canonical) raise_exception_err_ra(); <==== HERE + POPQ_RA(sp, new_cs, retaddr); + new_cs &= 0xffff; + if (is_iret) { + POPQ_RA(sp, new_eflags, retaddr); + } + } else +#endif + + + +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/125 + + diff --git a/results/classifier/semantic-bugs/mistranslation/1830872 b/results/classifier/semantic-bugs/mistranslation/1830872 new file mode 100644 index 000000000..ea6c495b1 --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/1830872 @@ -0,0 +1,612 @@ +mistranslation: 0.745 +other: 0.741 +vnc: 0.722 +instruction: 0.712 +KVM: 0.677 +semantic: 0.670 +graphic: 0.668 +device: 0.664 +assembly: 0.656 +boot: 0.623 +network: 0.606 +socket: 0.594 + +AARCH64 to ARMv7 mistranslation in TCG + +The following guest code: + + https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S + +implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI +Development Kit II) library function. (CopyMem() basically has memmove() +semantics, to provide a standard C analog here.) The relevant functions +are InternalMemCopyMem() and __memcpy(). + +When TCG translates this aarch64 code to x86_64, everything works fine. + +When TCG translates this aarch64 code to ARMv7, the destination area of +the translated CopyMem() function becomes corrupted -- it differs from +the intended source contents. Namely, in every 4096 byte block, the +8-byte word at offset 4032 (0xFC0) is zeroed out in the destination, +instead of receiving the intended source value. + +I'm attaching two hexdumps of the same destination area: + +- "good.txt" is a hexdump of the destination area when CopyMem() was + translated to x86_64, + +- "bad.txt" is a hexdump of the destination area when CopyMem() was + translated to ARMv7. + +In order to assist with the analysis of this issue, I disassembled the +aarch64 binary with "objdump". Please find the listing in +"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at +hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180. + +And, I ran the guest on the ARMv7 host with "-d +in_asm,op,op_opt,op_ind,out_asm". Please find the log in +"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached. + +The TBs that correspond to (parts of) the InternalMemCopyMem() and +__memcpy() functions are scattered over the TCG log file, but the offset +between the "nice" disassembly from "DxeCore.objdump", and the in-RAM +TBs in the TCG log, can be determined from the fact that there is a +single prfm instruction in the entire binary. The instruction's offset +is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy() +function --, and its RAM address is 0x472d2180 in the TCG log. Thus the +difference (= the load address of DxeCore.efi) is 0x472a7000. + +QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch +'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21). + +The reproducer command line is (on an ARMv7 host): + + qemu-system-aarch64 \ + -display none \ + -machine virt,accel=tcg \ + -nodefaults \ + -nographic \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \ + -cpu cortex-a57 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline \ + -serial chardev:char0 + +The apparent symptom is an assertion failure *in the guest*, such as + +> ASSERT [DxeCore] +> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090): +> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength + +but that is only a (distant) consequence of the CopyMem() +mistranslation, and resultant destination area corruption. + +Originally reported in the following two mailing list messages: +- http://<email address hidden> +- http://<email address hidden> + + + +Possibly related: +[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html + +(qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when QEMU is built for i686) + +Note to self: try to reprodouce the present issue with QEMU built at eed5664238ea^ -- this LP has originally been filed about the tree at a4f667b67149, and that commit contains eed5664238ea. So checking at eed5664238ea^ might reveal a difference. + + +Laszlo Ersek (Red Hat) <email address hidden> writes: + +> Possibly related: +> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html +> +> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when +> QEMU is built for i686) +> +> Note to self: try to reprodouce the present issue with QEMU built at +> eed5664238ea^ -- this LP has originally been filed about the tree at +> a4f667b67149, and that commit contains eed5664238ea. So checking at +> eed5664238ea^ might reveal a difference. + +Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough +cases. + +-- +Alex Bennée + + + +Alex Bennée <email address hidden> writes: + +> Laszlo Ersek (Red Hat) <email address hidden> writes: +> +>> Possibly related: +>> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html +>> +>> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when +>> QEMU is built for i686) +>> +>> Note to self: try to reprodouce the present issue with QEMU built at +>> eed5664238ea^ -- this LP has originally been filed about the tree at +>> a4f667b67149, and that commit contains eed5664238ea. So checking at +>> eed5664238ea^ might reveal a difference. +> +> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough +> cases. + +Actually I do see something with i386 host running the aarch64 memory +test (although so far not with a armv7 host): + + ./qemu-system-aarch64 -monitor none -display none -M virt -cpu max -display none -semihosting -kernel tests/memory + +Gives: + + Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249, 248, 255Test complete: FAILED + +-- +Alex Bennée + + +When running on 32 bit TCG backends a wide unaligned load ends up +truncating data before returning to the guest. We specifically have +the return type as uint64_t to avoid any premature truncation so we +should use the same for the interim types. + +Hopefully fixes #1830872 + +Signed-off-by: Alex Bennée <email address hidden> +--- + accel/tcg/cputlb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +index cdcc3771020..b796ab1cbea 100644 +--- a/accel/tcg/cputlb.c ++++ b/accel/tcg/cputlb.c +@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, + && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 + >= TARGET_PAGE_SIZE)) { + target_ulong addr1, addr2; +- tcg_target_ulong r1, r2; ++ uint64_t r1, r2; + unsigned shift; + do_unaligned_access: + addr1 = addr & ~(size - 1); +-- +2.20.1 + + + +I confirm that QEMU works fine (for the use case originally reported in this LP ticket) when built at commit a6ae23831b, i.e. at the parent of eed5664238ea. + +В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а): +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); + +Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug is separate from #1830872 ? + +I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler .. +probably x86-64 testing on i686 requires either docker (I don't have this +) or 'real' cross-compiler (build with glibc support). + + +Sorry the patch in comment #5 wasn't visible when I wrote what would end up as comment #6. I'll test the patch later. Thanks! + +I managed to tweak the memory test enough to detect the failure on aarch64-on-armv7 and I the attached patch fixes it. Could you please double check with your test case? + +В сообщении от Monday 03 June 2019 18:51:40 Alex Bennée написал(а): +> I managed to tweak the memory test enough to detect the failure on +> aarch64-on-armv7 and I the attached patch fixes it. Could you please +> double check with your test case? +> + + +Hm, I manually applied path from LP(git diff disliked copypasted patch), +so for now git diff in qemu tree shows: + +diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +index cdcc377102..b796ab1cbe 100644 +--- a/accel/tcg/cputlb.c ++++ b/accel/tcg/cputlb.c +@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, + && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 + >= TARGET_PAGE_SIZE)) { + target_ulong addr1, addr2; +- tcg_target_ulong r1, r2; ++ uint64_t r1, r2; + unsigned shift; + do_unaligned_access: + addr1 = addr & ~(size - 1); +lines 1-13/13 (END) + +--------- + +but x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg +still hangs at 'booting the kernel" (it decompress OK) + +I make distclean'ed source tree and reconfigured it: + ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg --cross-cc-x86_64="/opt/kgcc64/bin/x86_64-unknown-linux-gnu-gcc-6.5.0" + +next, make -j 5 and test. + +Hm. + +I tried debug switches, it seems to hang a bit differently for two runs: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg -nographic -d in_asm,op,op_opt,op_ind,out_asm + +===================== + +IN: +0xffffffff810e8a63: 48 83 c3 64 addq $0x64, %rbx +0xffffffff810e8a67: eb c2 jmp 0xffffffff810e8a2b + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a63 0000000000000000 + movi_i32 tmp2,$0x64 + movi_i32 tmp3,$0x0 + mov_i32 tmp0,rbx_0 + mov_i32 tmp1,rbx_1 + add2_i32 tmp0,tmp1,tmp0,tmp1,tmp2,tmp3 + mov_i32 rbx_0,tmp0 + mov_i32 rbx_1,tmp1 + mov_i32 cc_src_0,tmp2 + mov_i32 cc_src_1,tmp3 + mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a67 0000000000000009 + movi_i32 cc_op,$0x9 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a2b + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c080 + set_label $L0 + exit_tb $0xf2f1c083 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a63 0000000000000000 + movi_i32 tmp2,$0x64 pref=0xff + movi_i32 tmp3,$0x0 pref=0xff + add2_i32 tmp0,tmp1,rbx_0,rbx_1,tmp2,tmp3 dead: 2 3 pref=0xff,0xff + mov_i32 rbx_0,tmp0 sync: 0 dead: 1 pref=0xff + mov_i32 rbx_1,tmp1 sync: 0 dead: 1 pref=0xff + mov_i32 cc_src_0,tmp2 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_src_1,tmp3 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_0,rbx_0 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_1,rbx_1 sync: 0 dead: 0 1 pref=0xff + discard cc_src2_0 pref=0xff + discard cc_src2_1 pref=0xff + discard cc_op pref=0xff mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a55 0000000000000021 + movi_i32 cc_op,$0x21 + movi_i32 tmp20,$0x0 + movi_i32 tmp21,$0x0 + brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a57 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c180 + set_label $L1 + goto_tb $0x1 + movi_i32 tmp6,$0x810e8a63 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c181 + set_label $L0 + exit_tb $0xf2f1c183 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a4c 0000000000000000 + + ---- ffffffff810e8a52 0000000000000000 + movi_i32 tmp1,$0x0 pref=0xff + movi_i32 tmp0,$0x64 pref=0xff + mov_i32 r14_0,tmp0 sync: 0 dead: 1 pref=0xf8 + mov_i32 r14_1,tmp1 sync: 0 dead: 1 pref=0xf8 + call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op sync: 0 1 dead: 0 1 2 3 4 5 6 7 8 pref=none,none + mov_i32 cc_dst_0,r14_0 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_1,r14_1 sync: 0 dead: 0 1 pref=0xffУбито + +(killed by me) + +================== + +IN: +0xffffffff810e8a61: eb ef jmp 0xffffffff810e8a52 + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a61 0000000000000000 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a52 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f22900 + set_label $L0 + exit_tb $0xf2f22903 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a61 0000000000000000 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a52 pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f22900 + set_label $L0 + exit_tb $0xf2f22903 + +OUT: [size=56] +0xf2f22980: 8b 5d f0 movl -0x10(%ebp), %ebx +0xf2f22983: 85 db testl %ebx, %ebx +0xf2f22985: 0f 8c 23 00 00 00 jl 0xf2f229ae +0xf2f2298b: e9 00 00 00 00 jmp 0xf2f22990 +0xf2f22990: c7 85 80 00 00 00 52 8a movl $0x810e8a52, 0x80(%ebp) +0xf2f22998: 0e 81 +0xf2f2299a: c7 85 84 00 00 00 ff ff movl $0xffffffff, 0x84(%ebp) +0xf2f229a2: ff ff +0xf2f229a4: b8 00 29 f2 f2 movl $0xf2f22900, %eax +0xf2f229a9: e9 69 46 c9 ff jmp 0xf2bb7017 +0xf2f229ae: b8 03 29 f2 f2 movl $0xf2f22903, %eax +0xf2f229b3: e9 5f 46 c9 ff jmp 0xf2bb7017 + +---------------- +IN: +0xffffffff810e8a52: 49 ff ce decq %r14 +0xffffffff810e8a55: 74 0c je 0xffffffff810e8a63 + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a52 0000000000000000 + mov_i32 tmp0,r14_0 + mov_i32 tmp1,r14_1 + mov_i32 tmp0,r14_0 + mov_i32 tmp1,r14_1 + movi_i32 tmp20,$0xffffffff + movi_i32 tmp21,$0xffffffff + add2_i32 tmp0,tmp1,tmp0,tmp1,tmp20,tmp21 + mov_i32 r14_0,tmp0 + mov_i32 r14_1,tmp1 + call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op + mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a55 0000000000000021 mov_i32 cc_dst_0,r14_0 sync: 0 dead: 1 pref=0xff + mov_i32 cc_dst_1,r14_1 sync: 0 dead: 1 pref=0xff + discard cc_src2_0 pref=0xff + discard cc_src2_1 pref=0xff + discard cc_op pref=0xff + + ---- ffffffff810e8a55 0000000000000021 + movi_i32 cc_op,$0x21 sync: 0 dead: 0 pref=0xff + movi_i32 tmp20,$0x0 pref=0xff + movi_i32 tmp21,$0x0 pref=0xff + brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1 dead: 0 1 2 3 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a57 pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f229c0 + set_label $L1 + goto_tb $0x1 + movi_i32 tmp6,$0x810e8a63 pref=0xff movi_i32 cc_op,$0x9 sync: 0 dead: 0 pref=0xff + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a2b pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f22b40 + set_label $L0 + exit_tb $0xf2f22b43 + +OUT: [size=116] +0xf2f22bc0: 8b 5d f0 movl -0x10(%ebp), %ebx +0xf2f22bc3: 85 db testl %ebx, %ebx +0xf2f22bc5: 0f 8c 5f 00 00 00 jl 0xf2f22c2a +0xf2f22bcb: 8b 5d 18 movl 0x18(%ebp), %ebx +0xf2f22bce: 8b 75 1c movl 0x1c(%ebp), %esi +0xf2f22bd1: 83 c3 64 addl $0x64, %ebx +0xf2f22bd4: 83 d6 00 adcl $0, %esi +0xf2f22bd7: 89 5d 18 movl %ebx, 0x18(%ebp) +Убито + +============================= + +try kernel I use (it works with qemu compiiled under 64-bit Slackware, and also with kvm on 32-bit x86) + +sha256sum /boot/bzImage-4.12.0-x64 +b4183376de17e8ea7a25094b7a526e99bcb8339b8703090684c93e0e0a50d284 /boot/bzImage-4.12.0-x64 + + +(+Igor) + +On 06/03/19 17:01, Alex Bennée wrote: +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); +> + +Applied on top of commit ad88e4252f09c2956b99c90de39e95bab2e8e7af: + +Tested-by: Laszlo Ersek <email address hidden> + +Thanks! +Laszlo + + + +Andrew Randrianasulu <email address hidden> writes: + +> В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а): +>> When running on 32 bit TCG backends a wide unaligned load ends up +>> truncating data before returning to the guest. We specifically have +>> the return type as uint64_t to avoid any premature truncation so we +>> should use the same for the interim types. +>> +>> Hopefully fixes #1830872 +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> accel/tcg/cputlb.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +>> index cdcc3771020..b796ab1cbea 100644 +>> --- a/accel/tcg/cputlb.c +>> +++ b/accel/tcg/cputlb.c +>> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +>> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +>> >= TARGET_PAGE_SIZE)) { +>> target_ulong addr1, addr2; +>> - tcg_target_ulong r1, r2; +>> + uint64_t r1, r2; +>> unsigned shift; +>> do_unaligned_access: +>> addr1 = addr & ~(size - 1); +> +> Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my +> bug is separate from #1830872 ? + +I think you've hit two - one of which we have just fixed. With my +expanded memory test on i386 I'm seeing a hang but it's ok @ +pull-demacro-softmmu-100519-1. Unfortunately bisecting through the slirp +move and other i386 Werror stuff is proving painful. + +> +> I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler .. +> probably x86-64 testing on i686 requires either docker (I don't have this +> ) or 'real' cross-compiler (build with glibc support). + + +-- +Alex Bennée + + +On Mon, 3 Jun 2019 16:01:20 +0100 +Alex Bennée <email address hidden> wrote: + +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> + +Fixes arm/virt bios-tables-test for me, so + +Tested-by: Igor Mammedov <email address hidden> + +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c79b288513587e960b + diff --git a/results/classifier/semantic-bugs/mistranslation/1861404 b/results/classifier/semantic-bugs/mistranslation/1861404 new file mode 100644 index 000000000..f905e83ae --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/1861404 @@ -0,0 +1,223 @@ +mistranslation: 0.825 +instruction: 0.821 +assembly: 0.797 +other: 0.797 +device: 0.782 +graphic: 0.773 +socket: 0.740 +network: 0.740 +semantic: 0.730 +KVM: 0.709 +boot: 0.708 +vnc: 0.697 + +AVX instruction VMOVDQU implementation error for YMM registers + +Hi, + +Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. + +The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). +It works with XMM registers (16 bytes) though. + +See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. + +``` +user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror + +user@ubuntu ~/Qemu % ./ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F + +user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). + +Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. + + +``` +static void gen_sse(CPUX86State *env, DisasContext *s, int b, + target_ulong pc_start, int rex_r) +{ + [...] + case 0x26f: /* movdqu xmm, ea */ + if (mod != 3) { + gen_lea_modrm(env, s, modrm); + gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); + } else { + [...] +``` + +``` +static inline void gen_ldo_env_A0(DisasContext *s, int offset) +{ + int mem_index = s->mem_index; + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); + tcg_gen_addi_tl(s->tmp0, s->A0, 8); + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); +} +``` + + + +Note: Qemu has been built with the following commands: +``` +% ./configure --target-list=x86_64-linux-user && make +OR +% ./configure --target-list=x86_64-linux-user --enable-avx2 && make +``` + +On Friday, January 31, 2020, Alex Bennée <email address hidden> wrote: + +> ** Tags added: tcg testcase +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1861404 +> +> Title: +> AVX instruction VMOVDQU implementation error for YMM registers +> +> +If I remember well, there is no support for AVX instructions in linux-user +mode. + +If that is true, how come handling of unsupported instruction went that far? + +Did you try other AVX instructions? + +Aleksandar + + + + +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> Tested with Qemu 4.2.0, and with git version +> bddff6f6787c916b0e9d63ef9e4d442114257739. +> +> The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers +> (32 bytes). +> It works with XMM registers (16 bytes) though. +> +> See the attached test case `ymm.c`: when copying from memory-to-ymm0 +> and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the +> first 16 of the total 32 bytes. +> +> ``` +> user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror +> +> user@ubuntu ~/Qemu % ./ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 +> 18 19 1A 1B 1C 1D 1E 1F +> +> user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 +> 00 00 00 00 00 00 00 00 +> ``` +> +> This seems to be because in `translate.c > gen_sse()`, the case +> handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always +> performs a 16 bytes copy using two 8 bytes load and store operations +> (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). +> +> Instead, the `gen_ldo_env_A0` function should generate a copy with a +> size corresponding to the used register. +> +> +> ``` +> static void gen_sse(CPUX86State *env, DisasContext *s, int b, +> target_ulong pc_start, int rex_r) +> { +> [...] +> case 0x26f: /* movdqu xmm, ea */ +> if (mod != 3) { +> gen_lea_modrm(env, s, modrm); +> gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); +> } else { +> [...] +> ``` +> +> ``` +> static inline void gen_ldo_env_A0(DisasContext *s, int offset) +> { +> int mem_index = s->mem_index; +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(0))); +> tcg_gen_addi_tl(s->tmp0, s->A0, 8); +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(1))); +> } +> ``` +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1861404/+subscriptions +> +> + + +Because the sse code is sloppy, and it was interpreted +as the sse instruction movdqu. + +AVX support was coded for GSoC last year, + +https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +but it has not been completely reviewed and committed. + +There is no support for AVX in master. + +Thanks for your answers. + +I thought the fact that there was not any warning/exception meant that VMOVDQU was supported, but if it's mistakenly interpreted as MOVDQU then I understand. + +I read the mailing list messages on the AVX GSoC you point out, but couldn't find any branch where this work is located. Is there a non-released version of this that can be tested? + +If I understand correctly, Qemu (or more precisely TCG) supports x86 SIMD instructions up to SSE4.1, but not AVX/AVX2/AVX-512? + +Thanks. + +Hi, + +I also noticed that the 4.2.0 release changelog mentions support for some AVX512 instructions. + +https://wiki.qemu.org/ChangeLog/4.2#x86 +``` +Support for AVX512 BFloat16 extensions. +``` + +Is this support in TCG or in another component? +If so, it would mean that TCG support some AVX512 instructions but not AVX. + +Also, allow me to ask again, where can I find the work of last year's GSoC on AVX support for TCG? + +> AVX support was coded for GSoC last year, +> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +Thanks. + +The "AVX512 BFloat16" patch is for KVM support. + +As for finding the GSoC work, please follow that link, +and the ones buried inside that. There are hundreds +of patches involved. + + +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/132 + + diff --git a/results/classifier/semantic-bugs/mistranslation/266 b/results/classifier/semantic-bugs/mistranslation/266 new file mode 100644 index 000000000..4824b4c1d --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/266 @@ -0,0 +1,14 @@ +mistranslation: 0.986 +instruction: 0.937 +device: 0.742 +semantic: 0.592 +network: 0.416 +other: 0.357 +graphic: 0.350 +boot: 0.238 +socket: 0.112 +assembly: 0.101 +vnc: 0.084 +KVM: 0.032 + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/semantic-bugs/mistranslation/427 b/results/classifier/semantic-bugs/mistranslation/427 new file mode 100644 index 000000000..c11b42a46 --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/427 @@ -0,0 +1,14 @@ +mistranslation: 0.924 +instruction: 0.887 +device: 0.849 +network: 0.621 +boot: 0.337 +socket: 0.323 +graphic: 0.321 +semantic: 0.236 +assembly: 0.194 +vnc: 0.187 +other: 0.178 +KVM: 0.003 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/semantic-bugs/mistranslation/508 b/results/classifier/semantic-bugs/mistranslation/508 new file mode 100644 index 000000000..b05d57a9e --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/508 @@ -0,0 +1,14 @@ +mistranslation: 0.964 +device: 0.838 +instruction: 0.772 +other: 0.598 +network: 0.591 +graphic: 0.501 +semantic: 0.261 +boot: 0.211 +assembly: 0.091 +vnc: 0.078 +socket: 0.066 +KVM: 0.009 + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/semantic-bugs/mistranslation/83 b/results/classifier/semantic-bugs/mistranslation/83 new file mode 100644 index 000000000..ca61d874d --- /dev/null +++ b/results/classifier/semantic-bugs/mistranslation/83 @@ -0,0 +1,14 @@ +mistranslation: 0.859 +instruction: 0.857 +device: 0.813 +other: 0.511 +graphic: 0.374 +boot: 0.370 +socket: 0.204 +semantic: 0.165 +vnc: 0.149 +network: 0.095 +assembly: 0.028 +KVM: 0.001 + +QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit |