diff for duplicates of <201906031835.13420.randrianasulu@gmail.com> diff --git a/a/content_digest b/N1/content_digest index a1f94d4..d07a29f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,13 +1,13 @@ "ref\020190603150120.29255-1-alex.bennee@linaro.org\0" "From\0Andrew Randrianasulu <randrianasulu@gmail.com>\0" - "Subject\0Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load\0" + "Subject\0Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load\0" "Date\0Mon, 3 Jun 2019 18:35:12 +0300\0" "To\0Alex Benn\303\251e <alex.bennee@linaro.org>\0" - "Cc\0qemu-devel@nongnu.org" + "Cc\01830872@bugs.launchpad.net" qemu-arm@nongnu.org - 1830872@bugs.launchpad.net - Richard Henderson <rth@twiddle.net> - " Paolo Bonzini <pbonzini@redhat.com>\0" + qemu-devel@nongnu.org + Paolo Bonzini <pbonzini@redhat.com> + " Richard Henderson <rth@twiddle.net>\0" "\00:1\0" "b\0" "\320\222 \321\201\320\276\320\276\320\261\321\211\320\265\320\275\320\270\320\270 \320\276\321\202 Monday 03 June 2019 18:01:20 Alex Benn\303\251e \320\275\320\260\320\277\320\270\321\201\320\260\320\273(\320\260):\n" @@ -43,4 +43,4 @@ "probably x86-64 testing on i686 requires either docker (I don't have this\n" ) or 'real' cross-compiler (build with glibc support). -67144d90acb0e710eddc0acfba1346032e9843c069fa7bb7ba9edb6205e481d0 +810c1ce1e6dda80559de8a9a641b70cd4c20c9296b48fc9af9b2dbd7703e315d
diff --git a/a/1.txt b/N2/1.txt index 155f0a4..3ae6df9 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -25,8 +25,98 @@ > 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 ? +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). + +-- +You received this bug notification because you are a member of qemu- +devel-ml, which is subscribed to QEMU. +https://bugs.launchpad.net/bugs/1830872 + +Title: + AARCH64 to ARMv7 mistranslation in TCG + +Status in QEMU: + New + +Bug description: + 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://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com + - http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions diff --git a/a/content_digest b/N2/content_digest index a1f94d4..9865535 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,13 +1,9 @@ + "ref\0155912118291.12579.8926874795813611531.malonedeb@soybean.canonical.com\0" "ref\020190603150120.29255-1-alex.bennee@linaro.org\0" - "From\0Andrew Randrianasulu <randrianasulu@gmail.com>\0" - "Subject\0Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load\0" - "Date\0Mon, 3 Jun 2019 18:35:12 +0300\0" - "To\0Alex Benn\303\251e <alex.bennee@linaro.org>\0" - "Cc\0qemu-devel@nongnu.org" - qemu-arm@nongnu.org - 1830872@bugs.launchpad.net - Richard Henderson <rth@twiddle.net> - " Paolo Bonzini <pbonzini@redhat.com>\0" + "From\0Andrew Randrianasulu <1830872@bugs.launchpad.net>\0" + "Subject\0[Qemu-devel] [Bug 1830872] Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load\0" + "Date\0Mon, 03 Jun 2019 15:35:12 -0000\0" + "To\0qemu-devel@nongnu.org\0" "\00:1\0" "b\0" "\320\222 \321\201\320\276\320\276\320\261\321\211\320\265\320\275\320\270\320\270 \320\276\321\202 Monday 03 June 2019 18:01:20 Alex Benn\303\251e \320\275\320\260\320\277\320\270\321\201\320\260\320\273(\320\260):\n" @@ -37,10 +33,100 @@ "> do_unaligned_access:\n" "> addr1 = addr & ~(size - 1);\n" "\n" - "Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug is separate from #1830872 ?\n" + "Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug\n" + "is separate from #1830872 ?\n" "\n" "I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler ..\n" "probably x86-64 testing on i686 requires either docker (I don't have this\n" - ) or 'real' cross-compiler (build with glibc support). + ") or 'real' cross-compiler (build with glibc support).\n" + "\n" + "-- \n" + "You received this bug notification because you are a member of qemu-\n" + "devel-ml, which is subscribed to QEMU.\n" + "https://bugs.launchpad.net/bugs/1830872\n" + "\n" + "Title:\n" + " AARCH64 to ARMv7 mistranslation in TCG\n" + "\n" + "Status in QEMU:\n" + " New\n" + "\n" + "Bug description:\n" + " The following guest code:\n" + "\n" + " https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S\n" + "\n" + " implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI\n" + " Development Kit II) library function. (CopyMem() basically has memmove()\n" + " semantics, to provide a standard C analog here.) The relevant functions\n" + " are InternalMemCopyMem() and __memcpy().\n" + "\n" + " When TCG translates this aarch64 code to x86_64, everything works\n" + " fine.\n" + "\n" + " When TCG translates this aarch64 code to ARMv7, the destination area of\n" + " the translated CopyMem() function becomes corrupted -- it differs from\n" + " the intended source contents. Namely, in every 4096 byte block, the\n" + " 8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,\n" + " instead of receiving the intended source value.\n" + "\n" + " I'm attaching two hexdumps of the same destination area:\n" + "\n" + " - \"good.txt\" is a hexdump of the destination area when CopyMem() was\n" + " translated to x86_64,\n" + "\n" + " - \"bad.txt\" is a hexdump of the destination area when CopyMem() was\n" + " translated to ARMv7.\n" + "\n" + " In order to assist with the analysis of this issue, I disassembled the\n" + " aarch64 binary with \"objdump\". Please find the listing in\n" + " \"DxeCore.objdump\", attached. The InternalMemCopyMem() function starts at\n" + " hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.\n" + "\n" + " And, I ran the guest on the ARMv7 host with \"-d\n" + " in_asm,op,op_opt,op_ind,out_asm\". Please find the log in\n" + " \"tcg.in_asm.op.op_opt.op_ind.out_asm.log\", attached.\n" + "\n" + " The TBs that correspond to (parts of) the InternalMemCopyMem() and\n" + " __memcpy() functions are scattered over the TCG log file, but the offset\n" + " between the \"nice\" disassembly from \"DxeCore.objdump\", and the in-RAM\n" + " TBs in the TCG log, can be determined from the fact that there is a\n" + " single prfm instruction in the entire binary. The instruction's offset\n" + " is 0x2b180 in \"DxeCore.objdump\" -- at the beginning of the __memcpy()\n" + " function --, and its RAM address is 0x472d2180 in the TCG log. Thus the\n" + " difference (= the load address of DxeCore.efi) is 0x472a7000.\n" + "\n" + " QEMU was built at commit a4f667b67149 (\"Merge remote-tracking branch\n" + " 'remotes/cohuck/tags/s390x-20190521-3' into staging\", 2019-05-21).\n" + "\n" + " The reproducer command line is (on an ARMv7 host):\n" + "\n" + " qemu-system-aarch64 \\\n" + " -display none \\\n" + " -machine virt,accel=tcg \\\n" + " -nodefaults \\\n" + " -nographic \\\n" + " -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \\\n" + " -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \\\n" + " -cpu cortex-a57 \\\n" + " -chardev stdio,signal=off,mux=on,id=char0 \\\n" + " -mon chardev=char0,mode=readline \\\n" + " -serial chardev:char0\n" + "\n" + " The apparent symptom is an assertion failure *in the guest*, such as\n" + "\n" + " > ASSERT [DxeCore]\n" + " > /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):\n" + " > Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength\n" + "\n" + " but that is only a (distant) consequence of the CopyMem()\n" + " mistranslation, and resultant destination area corruption.\n" + "\n" + " Originally reported in the following two mailing list messages:\n" + " - http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com\n" + " - http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com\n" + "\n" + "To manage notifications about this bug go to:\n" + https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions -67144d90acb0e710eddc0acfba1346032e9843c069fa7bb7ba9edb6205e481d0 +c810861923724cdb3a1d45086847c996e174a98935b8db6922ea006a1b0800c5
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.